Welcome to AddressOf.com Sign in | Help

Structured Error Handling... My oppinion on the subject.

I've seen a couple of posts concerning the evils that VB.NET has concerning the following:

Try
Catch ex As Exception
End Try

Kirk Allen Evans points out how VB.NET's autocomplete is Propagating Improper SEH.  Charles Torre points out how this can “very dangerous since it can expose stack-based buffer overrun exploits”.

Kirk and I have spoken via instant messenger on this at considerable length and I agree with him on some of his points we discussed, but I don't agree that what both of these guys are saying publicly about using As Exception.  Kirk points out that because As Exception will catch ALL exceptions, it's possible that when you get an really critical error such as Overflow Exception, that you not be allowing the OS to handle the error properly.  I don't agree with this. 

First, if this is true, then the .NET CLR needs to be changed accordingly.  Second, if you are developing a Windows Forms application (or console application), you need to do whatever is necessary to either handle ALL errors gracefully or, in the case you can't, present the error in a way the user can utilize the error to fix whatever problem is occuring and possibly be able to report (or log) that error accordingly so that you can debug the deployed application and get it resolved.

Imagine running Microsoft Office Word 2003 and it popping up with one of the generic .NET error boxes because Microsoft didn't take the necessary steps to handle or recover the error.  The errors that were pointed out to me shouldn't make it out the door; those types of errors should occur under testing conditions and be pretty easy to reproduce.

As a user of an application, I expect to have a certain type of user experience... error messages are not, in my oppinion, part of the experience I wish to see.  However, if they must exist, I want to see one that helps me continue using the application, not just exist and throw all my hard work out the window because the developer didn't do their job properly.  Nothing makes me more angry than losing some document that I've been working hard on for the past three hours.  I'm sure others feel the same way.

As for catching errors As Exception exposing you to “stack-based buffer overrun exploits”; I don't agree with this.  I don't think that how you catch errors has anything to do with these type of exploits.  From what I understand, these exploits take advantage of some languages ability to blindly copy memory from one location to another (pointers); possibly overwritting memory that shouldn't be overwritten (that was not allocated).  Within this region, executable code is placed and upon returning from a calling method; this code can execute due to how stack-based method calls work.  Because .NET is a type-safe environment, this is not possible unless there is some sort of bug in the CLR.

Also, I want to point out that just because you catch an error, if you can't handle it and it's something that is definately a critical error, then you should rethrow this error.  Another point is that this argument can be seen from two different camps.  One is the Windows Forms / Console applications where you actually have a user.  The other is the ASP.NET / Windows Services where your applications are unattended.  You don't have the luxury of presenting a nice error message with possible fixes.  There's no one to correct the issue at hand and resume the application.  With smart clients, you have a user there.  They need to know something happened.

Both of these guys point out the Chris Brumme blog entry (which I think everyone should read) as their source for backing up their perspective.  The problem is that I don't really see how his post backs up their argument... unless you are talking about try/catch in relationship to C++ (Managed/Unmanaged).  Also, Chris's post specifically points out that you should be using Managed Code because of the protection against possible buffer overrun exploits; thus completely contradicting Charles Torre's statement.

Finally, maybe Paul Vick and jump in and add why VB.NET autocomplete does the Catch ex As Exception.  I'd be interested in hearing the reasons behind this (I think I know what they are, but it'd be nice to hear it from the expert(s) ;-) )

Published Wednesday, February 04, 2004 3:35 AM by CorySmith
Filed under: ,

Comments

# re: Structured Error Handling... My oppinion on the subject.

Wednesday, February 04, 2004 4:29 AM by Paul Vick
As far as exception handling in general goes, I think your logic is correct. As a developer, it's my responsibility to handle exceptions properly and not let them escape to the generic "unhandled exception" dialog in the CLR. And I'm not aware of _any_ possible buffer overrun exploits in unmanaged code. So I don't see any problems with pasting in "Catch ex As Exception".

As to your question, we paste the code in because it is a syntax error to have a Try...End Try without no Catch or Finally. The general principle we've followed is that autocomplete should never create errors, so we needed to put something in there. "Finally" would be an option, but we felt that "Catch ex As Exception" would be more understandable. Our assumption is that the first thing that people will do is specialize the exception, anyway...

# re: Structured Error Handling... My oppinion on the subject.

Wednesday, February 04, 2004 8:51 PM by Kirk Allen Evans
> Our assumption is that the first thing that people will do is specialize the exception, anyway...

The problem is that most people don't, they swallow the error. I have spoken on Exceptions at a number of user groups, and at each one I hear "well why would you go through the trouble of creating a new Exception type when you can just catch Exception?"

And I don't claim that there is a possible buffer overrun exploit in unmanaged code, that was Charles Torre's post. The part that I was referring to in Brumme's post regarded the StackOverflowException.

If you have a method that reasonably expects a StackOverflowException, then by all means catch it and process it. But if your method is not prepared to do anything with a StackOverflowException, then it should bubble to the caller. The caller, then, is responsible for doing something to respond to unforseen behavior. Whether that is logged, displayed, bubbled to the AppDomain.UnhandledExceptionEventHandler, or is bubbled to the default handler is up to the caller.

More importantly, methods should not catch Exception because StackOverflowException as well as ExecutionEngineException could happen at any time without relation to the current method. Although the docs state that EngineExecutionException should never happen, a version of the Oracle ODP.NET driver did cause this to happen in ASP.NET apps.

My problem with autocompleting "Catch ex As Exception" is that many developers perceive this as the correct way to code, period. An app I recently worked on sparked a long debate about this because there were no typed exceptions, everything was typed as Exception.

I think that autocompleting "Finally" would be more appropriate, because the developer has to explicitly type the Exception derivative that they could reasonably handle within a method, akin to the C# using statement.

# Exceptions and VB.NET, Revisited

Wednesday, February 04, 2004 9:32 PM by Kirk Allen Evans' XML Blog

# re: Structured Error Handling... My oppinion on the subject.

Thursday, February 05, 2004 1:17 PM by Kirk Allen Evans
Cowboy (Gregory A. Beamer) IM'd me with some additional reinforcement for not catching System.Exception, but the explicit type:

From the Exception Management in .NET book:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/exceptdotnet.asp

"You should only catch exceptions when you need to specifically perform any of the following actions:

Gather information for logging
Add any relevant information to the exception
Execute cleanup code
Attempt to recover

If a particular method does not need to perform any of these actions, it should not catch the exception; rather, it should allow it to propagate back up the call stack. This keeps your code clean and explicit as you only catch the exceptions that need to be handled within the scope of a particular method and allow all others to continue to propagate."

# Exceptions and VB.NET, Revisited

Thursday, February 05, 2004 1:21 PM by Kirk Allen Evans' XML Blog
Anonymous comments are disabled