Page 131 - DCAP312_WEB_TECHNOLOGIES_II

Unit 6: Error Handling

0xe0434f4d is the exception code for CLR (.net) exceptions, so any managed exception like Notes
a NullReferenceException or InvalidOperationException or SQLException… basically all
managed exception are natively referred to as 0xe0434f4d. In this case, if we look closer at
the application event log entry we can see that it is in fact a System.DivideByZero exception.
Trivia: Just a piece of info of no particular value that you might want to pull out of pocket
on your next dateJ 0xe0434f4d or at least 43 4f 4d are the ASCII values for the letters COM.
But now should a .net exception cause the asp.net process to crash??? If you divide by zero
in your page and do not have a try catch block around it, surely you will get one of those
“nice “ white and yellow error pages saying that an exception occurred on your page, but
the process does not just exit.
The answer is yes, you will get one of those pages because the asp.net global error handler
will eventually catch your exception, format it for you and print it out on the screen. But what
happens if it is not on an asp.net request, so there is no-one to feedback the exception to? It
is the old paradox: If a tree falls in the forest and nobody is there, does it still make a sound?
In 1.0 and 1.1 it did not. For example if you throw an exception in a piece of code called
on a timer, or use QueueUserWorkItem and throw an exception in code executing there,
or otherwise throw exceptions in code that is not running inside the context of an asp.net
request, the framework will swallow the exception and continue. Or rather it will stop that
thread of execution but it would not die.
Does not sound all that bad right?
That thread could have been doing anything, and we will never be the wiser that it died. It
could have been holding a lock of some sort, or it could have been in the middle of cleaning
up resources, or really a number of different things that will now never happen, but that
may immediately or eventually have really bad side effects like hangs or crashes or memory
issues, but the exception will be long gone so we cannot figure out what it was.
The policy for unhandled exceptions was changed in ASP.NET 2.0 to the default for .net
which is a process exit. This can be changed back by adding the following to the aspnet.
config in the frameworks directory, but it would not recommend it without putting in some
preventive measures to take care of potential unhandled exceptions on non ASP.NET threads.
<configuration>
<runtime>
<legacyUnhandledExceptionPolicy enabled= “true “ />
</runtime>
</configuration>
Questions
1. What is the problem of ASP.NET crash?
2. What were the initial thoughts about this exception?

Self Assessment Questions

6. Which is not a type of error programmers look for?
( a) Logic (b) Runtime
( b) Superficial (d) Syntax

LOVELY PROFESSIONAL UNIVERSITY 125