Last post Aug 01, 2020 01:52 AM by PaulTheSmith
Jul 30, 2020 11:35 AM|mrwww76|LINK
Using the latest Visual Studio 2019. Is there a way to tell the Debugger to ignore handled exceptions?
On startup of my application on localhost a NullReferenceException can be thrown. This is entirely expected and properly handed in the code via a try/catch block. However, the debugger insist on performing a break on error even though I've handled it.
Yes, I know I can tell the debugger to ignore specific CLR errors. The problem is that enabling this feature instructs the debugger to ignore ALL errors of said type. This will not help me. I want to know when a NullReferenceException occurs
if I didn't handle it in a try/catch block
Jul 30, 2020 12:56 PM|mgebhard|LINK
Seems like a trivial fix. Check if the instance is null before trying to access members of the null type.
Jul 30, 2020 01:44 PM|mrwww76|LINK
You are correct in that I could do an if( object != null) check as a workaround. But if I have over a 2 dozen of these possibilities to check, it defeats the purpose of a try/catch. There are times a try/catch just makes things easier and more readable
(unless I was getting paid by the # of lines of code). I know the question was asked over 10 years ago for a feature for debugger to ignore handled exceptions. Basically what we got was ignoring all exception of a particular type. Just seeing if something
was ever created.
I guess it died on the vine much like when people have requested that SSMS have a dark theme for years. Yeah, you can hack out a workaround, but its never been officially supported despite it being one of the most requested features of SSMS.
Jul 30, 2020 02:41 PM|PatriceSc|LINK
Which version of VS do you use? You are 100% sure that https://docs.microsoft.com/en-us/visualstudio/debugger/managing-exceptions-with-the-debugger?view=vs-2019 still
doesn't allow that?
Jul 30, 2020 03:31 PM|mgebhard|LINK
You are correct in that I could do an if( object != null) check as a workaround. But if I have over a 2 dozen of these possibilities to check, it defeats the purpose of a try/catch.
Try...catch is NOT designed for this purpose. It's designed to catch unhanded exceptions not be used as validation or part of the logical flow. Your design approach wastes resources.
I know the question was asked over 10 years ago for a feature for debugger to ignore handled exceptions. Basically what we got was ignoring all exception of a particular type. Just seeing if something was ever created.
Most developers do not use try...catch in their program flow. I use the ?. and ?? operators these days for dealing with null.
List<string> list = null;
Keep in mind, your proposed solution means you have to go to the line of code you wish to ignore and tell the debugger to not break on the line. Seems like it would be quicker and easier to write "good" code in the first place.
Jul 30, 2020 05:46 PM|mrwww76|LINK
I reviewed the link you provided a few responses ago and what I was looking for was the opposite of what the Debugger > Windows > Exceptions currently does... which was to
continue when the exceptions IS handled, which it currently not designed to do at least in a development environment.
But you do make some valid points with regards to the try/catch intended purpose which is to catch exception for which the developer did not account for. If I know something MAY happen I need to try and deal with it. In this particular case the level of
detailed exception handling was not required so long as it didn't crash the program. The try/catch is how I chose to deal with it as it greatly reduces the code footprint and accomplishes the same task as if I needed to be very explicit in my error handing.
Jul 31, 2020 07:52 AM|PatriceSc|LINK
You tried with NullReferenceException being unchecked and other columns left blank? Seems fine here with VS 2019 (and AFAIK was the same in older version).
Still consider https://docs.microsoft.com/en-us/dotnet/standard/exceptions/best-practices-for-exceptions#handle-common-conditions-without-throwing-exceptions once
Aug 01, 2020 01:52 AM|PaulTheSmith|LINK
Without wanting to start a flame war ...
An Exception is, by definition, something that is exceptional. If you expect something to happen then it is not 'exceptional'. You are expecting a variable to be null sometimes - this is not an Exception. You are trying to use a mechanism outside its
intended purpose and then want to bend it back to what you want.
It is, generally, much easier to use things the way they are intended. If a variable being null is a problem then check it and take action. If something exceptional happens then use the Exception mechanism.
Just my 2c