When writing for ASP.NET and, while the debugger is attached, if you visit a web page that throws an exception, the unhandled exception helper is launched at the line of code that caused the exception.

This occurs even if you only are catching unhandled exceptions and are not catching thrown exceptions. However, hitting F5, ignoring the exception, or not having the debugger attached does not cause the AppDomain to be torn down. Instead somehow ASP.NET handles the unhandled exception anyway.

How does this work, and can exception handling like this be implemented elsewhere so that other unhandled exceptions can be swallowed rather than kill the whole AppDomain or process?

Edit: To clarify, I understand how exception handling and try...catch blocks work. However, in this case it seems that the debugger is considering the exception unhandled while at the same time ASP.NET is wrapping the exception in a try...catch. That is the behavior I want to emulate.

  • I think the exception is handled by flushing the uppermost exception's description details and stacktrace to the HttpResponse. You could do this too I believe. – TWickz Jul 28 '12 at 11:31
  • The key here seems to be user-unhandled vs unhandled. – David Pfeffer Jul 28 '12 at 15:47
  • And the down vote is because...? If this is such a simple question, why was no one able to explain how the debugger determines "your code" from "system code?" – David Pfeffer Jul 30 '12 at 12:12
  • 1
    Good question. I am upvoting to level the scores. – TWickz Jul 30 '12 at 12:20
up vote 2 down vote accepted

How does this work,

just wraps executing code in whatever exception-handling code they want. asp.net webpage (or view, or controller) is just a class, and how to use it is entirely up to host (in our case, asp.net).

why does VS debugger break on it if it's handled?

There's a quote from MSDN documentation:

ASP.NET has a top-level exception handler that handles exceptions to show error pages to browser users. That top-level exception handler will stop an unhandled exception from breaking into the debugger unless Just My Code is turned on. Make sure that you enable Just My Code for ASP.NET debugging.

Which means that if you have "Just my code" enabled in VS Debug options (and it's enabled by default) you'll break at exceptions that are unhandled in your own code, irregardless of whether they are handled in your caller or not.


You can't do that, it is a security measure.

  • So your question is "why VS Debugger think it's an unhandled exception"? Because it's not handled in user code. I'll add detailed quote and link to post. – Serg Rogovtsev Jul 28 '12 at 12:07
  • This makes sense, but in practice does not seem to work. For example, I use the MassTransit message bus library, and when a message handler (my code) fails, MassTransit ("system" code) handles it, logs it with NLog, and proceeds happily onward. The user-unhandled exception helper never pops up. – David Pfeffer Jul 28 '12 at 12:17
  • That means that VS Debugger did not recognize MassTransit as "not your code". – Serg Rogovtsev Jul 28 '12 at 12:48
  • How does it decide? – David Pfeffer Jul 28 '12 at 14:27
  • 1
    Frankly, I don't know. From what we've seen while debugging third-party code it somehow relies on PDBs and some other knowledge. Anyway, it is just a filtering inside debugger, not some magic to turn unhandled exceptions into handled or vice versa. – Serg Rogovtsev Jul 28 '12 at 14:59

Your webpage is just a bunch of method calls from IIS & the ASP.NET Runtime, you're webpage isn't running alone in your appdomain. The code calling into your code has an ordinary try/catch block around that method call.

You could create a similar setup yourself:

The problem with these kinds of programs then would be: Where in the app should you continue?

The last question is solved easily in ASP.NET, since every page call is isolated from each other. The user just continues by navigating to a page again.

  • This doesn't answer the fundamental question -- if the whole thing is wrapped in a try/catch block, why is it being considered unhandled and not just thrown by the debugger? – David Pfeffer Jul 28 '12 at 12:02
  • Because it's not handled in user code. VS Debugger does not know if it's handled somewhere deep inside IIS module. – Serg Rogovtsev Jul 28 '12 at 12:03
  • @SergRogovtsev Of course it does. That's the nature of exception handling. Show me any other example of where user code doesn't handle an exception but the caller does, and yet an unhandled exception handler is still popped up. – David Pfeffer Jul 28 '12 at 12:05
  • 1
    @DavidPfeffer: Good question... Framework code is in that sense no different from your code. Could it be that the debugger somehow knows about what are standard framework classes, or is there an attribute maybe? – Arjan Einbu Jul 28 '12 at 12:07
  • 2
    @ArjanEinbu there is an unsubtle difference between your code (which means "code from current solution that is compiled from sources") and all the other code (that you reference as assemblies). That's what "Just My Code" option in debugger knows. – Serg Rogovtsev Jul 28 '12 at 12:13

Your Answer


