Structured Error Handling... My opinion 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 occurring 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 opinion, 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 overwriting 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 definitely 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 can 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) ;-) )