locked
Debugger: Ignore handled exceptions? RRS feed

  • Question

  • User948188685 posted

    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

    Thursday, July 30, 2020 11:35 AM

All replies

  • User475983607 posted

    Seems like a trivial fix.  Check if the instance is null before trying to access members of the null type.

    Thursday, July 30, 2020 12:56 PM
  • User948188685 posted

    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. 

    Oh well

    Thursday, July 30, 2020 1:44 PM
  • User753101303 posted

    Hi,

    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?

    Thursday, July 30, 2020 2:41 PM
  • User475983607 posted

    mrwww76

    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. 

    mrwww76

    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.

    https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/member-access-operators#null-conditional-operators--and-

    https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/operators/null-coalescing-operator

    List<string> list = null;
    list?.Add("Hello");
    Console.Write("Hello World");

    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.

    Thursday, July 30, 2020 3:31 PM
  • User948188685 posted

    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. 

    Thursday, July 30, 2020 5:46 PM
  • User753101303 posted

    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 ready.

    Friday, July 31, 2020 7:52 AM
  • User303363814 posted

    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

    Saturday, August 1, 2020 1:52 AM