Whenever I have a try/catch statement in my own code, the Exception still breaks to debugger.
I can turn off the check Break when this exception type is
thrown.
I don't want to do that because I do want to break in all other cases that I don't have a try/catch.
I can turn Except when thrown from this dll. I don't want to that for the exact same reason. There are valid reasons in that DLL why I want to break when I do not try/catch it myself.
I just want to not break when I have a try/catch statement, because I am already handling it so I don't want to be bugged by every external call that is failing.
How can I do this?
UPDATE
This mainly seems to be a problem with ASP.NET. Probably because there is one big try/catch per request in the outermost ASP.NET layer.
So what I'm looking for in a way is something like:
Break only try/catched in external code.
Maybe I don't understand your question but if you just take out "Break when this exception type is thrown" you should have the exact behaviour you want. The debugger will still break if the exception isn't caught. The only thing this checkbox does is tell the debugger to break even if the exception got caught.
If this is not the behaviour you want I may need some clarification to understand your question.
Edit:
Since you've now edited your question and you seem to be looking for "Break only try/catched in external code.", I can only tell you that I wouldn't know of such a feature and have never used anything like that. That does not mean it doesn't exist though.
Related
When I'm building my programs, I have a number of try-catch blocks and when they throw errors, I seem to have trouble seeing what caused the error - I've tried looking at the stack-trace but I always end up commenting out the error handling and re-running.
Is there a better way? (I'm sure there must be ...)
If every time I have to comment out the bits of my try-catch to figure out why it was throwing it seems like I should be able to look at the stack-trace or something. Sorry if it's a simple question but it should have a simple answer ...
In Visual Studio, do the follow steps:
Menu [Debug]
Option [Exceptions...]
On the right of [Common Language Runtime Exceptions], check the box under [Thrown].
Now your application will always stop (as if it is a breakpoint) at the line where an exception is thrown.
When debugging a C# program with Visual Studio, how can you see if the code you're stepping through is in a try/catch block?
That is, if the code throws an exception, will the exception be caught by another part of the program or not?
The problem is that there's an application which is prone to crashing when used out in the wild, but we can't replicate the problem here under the debugger, and we think that all exceptions are caught, but apparently we're wrong!
And it's a large program, with lots of classes and event handlers and timers, so it's not always straightforward in which order things are executed.
So, how can you tell which parts of a program have potential uncaught exceptions, other than stepping up through the call stack constantly to see if you find a try?
You may need AppDomain.UnhandledException
The title may be a little confusing so I'll explain. Say you had this call chain...
public DoWork(index) >> private DoWorkHelper(index) >> private CheckIndex(index)
Now if you call DoWork, it traverses the calls down to CheckIndex, adding each deeper call to the call stack.
Now if someone calls DoWork with a bad value for index, it throws the exception all the way down at CheckIndex, and currently, that's where the debugger breaks. You then have to walk back up the call stack to see the real offender was that someone passed bad data to DoWork.
Now back in the VB6 days, you could simply decorate DoWorkHelper and CheckIndex with an attribute to say 'If any exception is thrown inside me, don't highlight me, but rather my caller because they were the ones that passed me bad crap!' So in this case, the code would break inside DoWork with the call to DoWorkHeper highlighted.
There was also a setting to disable this so for deeper debugging purposes it could still be thrown at CheckIndex, the level where it actually occurred, but half the time, breaking down there tells you nothing because you don't know how you got there without walking back up the call stack.
Think of it a way to decorate your code to say when you hit an exception, auto-traverse the call stack to the point where the bad value actually tells you something useful.
Note this is similar to 'Break On All Exceptions' except you're handling this via decoration. Plus, you're not setting to break on a specific type of exception (e.g. all null reference exceptions, etc.) but rather a specific method! (or more accurately, the one that called the decorated method.)
So does C# or .NET in general have this?
Update
While I credit Dark Falcon for the answer since he directed me there, I've added a more detailed explanation about what all the attributes mean, and in what context. Check it out below.
Please see the Just My Code option. You need to decorate DoWorkHelper with DebuggerHiddenAttribute or DebuggerNonUserCodeAttribute.
Just adding what I've found to better explain so people don't have to go looking elsewhere...
There are three attributes related to this: DebuggerHidden, DebuggerStepThrough, and DebuggerNonUserCode.
Here are the rules:
When Just My Code is not checked:
DebuggerNonUserCode
This is basically ignored. Breakpoints, step-into and exceptions all work the same as if this attribute wasn't there.
DebuggerStepThrough
This respects breakpoints and will break on exceptions where they occur, but you cannot manually step into blocks marked with this attribute.
DebuggerHidden
This doesn't allow you to step in to these blocks, it ignores breakpoints, and any exceptions thrown are handled in the calling method, not where they actually occur.
When Just My Code is checked
All three attributes behave the same as if you had used DebuggerHidden above.
There's another attribute, DebuggerStepperBoundary that is pretty cool. Here's the excerpt from MSDN:
Use the DebuggerStepperBoundaryAttribute to escape from stepping through code to running code. For example, in Visual Studio 2005, encountering a DebuggerStepperBoundaryAttribute while stepping through code using the F10 key (or Step Over command) has the same effect as pressing the F5 key or using the Start Debugging command.
Hope this clears things up! Sure did for me!
I have an ASP.NET web app which is small yet has a fair amount of C# behind it.
I am trying to run some code, which is dependent on a class library/.dll I have produced (containing business logic). When I debug, after I bind to datasource property, I get an object reference not set to an instance object.
I know how to fix these errors as I have done more than my fair show when I lacked experience, but the trouble I have is I cannot find the last method to execute (which will in turn help me find the variable at fault) until this exception. Is there a way I can make the code break when it reaches the line of code causing this exception (or the line of code matching the last method called in the stacktrace)? I will probably do a find for that method signature but I don't really like this approach. Is this something for windbg?
I guess this is what they mean by unmaintainable code.
Look at the stack trace that is most likely printed out with the error.
Also try breaking on exceptions - Debug Menu -> Exceptions, Choose CLR Exceptions
VS should highlight the line from which the exception was thrown. If it doesn't, you can enable it in Debug > Exceptions. If you put a breakpoint on or before this line (or if it doesn't give you a line, on or before the code you suspect of throwing it), and then "Step In" repeatedly, you will eventually reach the code where the exception is thrown.
If I'm writing a class library, and at some point in that library I have code to catch an exception and deal with it, then I don't want anyone using my library to know that it even happened - it should be invisible from the outside world.
However, if they have "Catch Thrown Exceptions" turned on in Visual Studio (as opposed to "Catch User Unhandled Exceptions") then the exception will be visible to them.
Is there any way to avoid this?
No. This is by design: as a developer, I run with "Catch Thrown Exceptions" turned on, so that I can see exceptions thrown in library code (and hopefully avoid them). The situation you're in applies equally to the .NET framework's own libraries too.
The best way would be to avoid throwing the exception in the first place. As a side benefit, you library code will be faster, since throwing an exception has a noticeable impact on performance (and should only be used in 'exceptional' circumstances).
The only way you can pull this off is if you put a [DebuggerHidden] attribute on the method that may throw the exception. Like others have pointed out, better to avoid the exception altogether, but this attribute will accomplish what you want.
You cannot prevent this. Someone can always attach an debuger to the process and monitor what is going on.
You could just remove the exception and provide the error handling yourself, but I would really not recommend that because it is some kind of reinventing the wheel - recreating the exception handling system.
The said applies of course only if the code throwing and the code catching the exception are far apart and quite unreleated. If they are tightly coupled, you should really check if the call can succeed and only call in this case. Always remeber that exception are intended for exceptional cases - not for normal control flow where you could check if the operation can succeed
As Tim Robinson suggests there is no way to control someone viewing exceptions thrown from your library. His answer is good so I won't rehash it.
There are a couple of posts here on SO that you may find helpful when addressing (what sounds like) using exceptions as program flow control:
Catching exceptions as expected program execution flow control?
Why are .Net programmers so afraid of exceptions?