DB2 SQL Statements throwing Exception

dynaTrace shows ALL exceptions that happen in your application - even those that are caught within the frameworks you are using. So - it is very likely that these exceptions are caught within the ADO.NET Framework and therefore never make it to our application code.

However - knowing that these exception occur - you could do some research to find out whether it is due to a configuration issue. Exceptions in general might not be bad - but - could be bad if they happen very often and if they can be avoided. In the end - every exception that you can prevent is time and performance saved

Andreas,

That is great.  I see them.  I cannot get a ArgumentException to be detected when running a debug on my computer in Visual Studio.

Do you have a suggestion as to how I can make Visual Studio more sensitive to capture the System.ArgumentException that DynaTrace is detecting?
I have tried a couple changes to the VS debug parameters to no avail.

I am not an expert in VS Debugging - but I know that there is a debugging setting that allows you to specify a list of Exceptions that will put a breakpoint when a certain exception is thrown. I am sure these exceptions - or better - the location where this exception is thrown - is currently not included in that list

I did find a checkbox specifically for "System.ArgumentException".  So far, no luck.  I will keep checking.

Does DynaTrace have a more detailed "dump" list?  I am looking only in the PurePath lists so far.

I have dug a little deeper:  Throwing Class = System.Enum,  Throwing Method = Parse.

I'm getting closer.

hi Steve,

doesn't the stacktrace of those exceptions already give you a good hint on where they occur?

you could also post the session here for us to look at.

best,

Christian

Christian,

Sure.  I can identify each DB method being executed.

In VS 2012 Ver 11, in debug mode, I have tried a variety of methods to try and capture the ArgumentException.
try{}/catch{} does not capture an exception.  The SQL statements work, return data, application functions as though nothing was wrong.

Every SQL statement, be it SELECT, UPDATE, DELETE, via ExecuteReader() or ExecuteScalar(), gets that neat little "exception" line red-x.

When I can get DynaTrace into another server location I can try some other DB2Command changes to see what (if any) will remove the exceptions.
I should be doing that in a day or two.

Thanks.

I think what Christian wanted to say is that you can right click on that Exception and open the Details Dialog. That will give you the FULL Stack trace for that Exception and "not just" the information in the PurePath which is typically not as deep as the stack trace.

Another hint for folks that are new to dynaTrace: You can open the Exception Dashlet (double click on it in the Cockpit). There you get the overview of all exceptions captured within e.g: the last 30 minutes. From there you can see the Details (Full Stack Trace) + you have the Option to Drill To those PurePaths where these exceptions are thrown.

correct, Andi explained it in more detail, but that's what i meant.  so with the full stack trace you should also see what the DB2 driver is doing inside.

I'm no expert in VS debugging, either, but i could imagine that setting breakpoints in code which is built as release without debug information - as the DB2 driver surely is - does not work. and of course you cannot catch the exception in your code, because it is thrown and caught below the DB call ... otherwise, if it would be thrown over the DB call, you would see a red cross icon on the DB call in the PurePath.