Try Catch vs. On Error Resume Next Error Handling

Unlike C#, VB has a feature that lets your code execute the next line after an error on the previous. This statement in VB is On Error Resume Next. It seems to be a hotly debated argument with supporters on both sides of the fence. Usually, the argument is that they rather return a code error on the page to the visitor so that the visitor is aware of the error. However, this is not always the best idea and it looks unprofessional. In my opinion, this On Error.. statement is actually very useful, if properly implemented, as it has a finer grain of error handling. Let's see what it looks like:

The On Error Resume Next statement looks something like this:

On Error Resume Next
Statement #1
Statement #2
Statement #3

Essentially, lets say that an error occurs on the Statement #1 line. Because On Error Resume Next was called in the beginning, the next line Statement #2 is executed and so on.

Now lets take a look at the Try Catch statement

Statement #1
Statement #2
Statement #3
}catch(Exception ex)
//do something with error here

In a Try-Catch statement, where an error occurs on Statement #1, statements #2 and #3 are skipped and the Catch section is executed. The only way to have statements #2 and #3 to execute would be to put every statement in its own Try-Catch block. Of course this would be very difficult to read and very tedious to do. A model class can easily be 1000 lines long and to put in a Try-Catch block every 5 lines would still be 200 blocks. Of course in reality practically nobody would actually do this. This means that with any error that occurs, it's guaranteed that some lines of code are going to be skipped which could cause a larger problem than the error itself.

Let me give you a real world example that I experienced. I've been developing e-commerce websites for a while now. However, when I started back around 2001 I was using ASP and the On Error Resume Next statement. It would log every error to the database and send an error email to me for review. Not too long after publishing a new ecommerce website, a customer put in an order and an unexpected error occured in processing the credit card with a HTTPS connection to the merchant gateway. This was not just a status error with the http client but rather an actual VBScript error. If the On Error Resume Next statement was not used, the customer would have seen an error message on a standard error page and the order would have failed. In that particular case, the next line of code executed and the order was saved into the database. Because the card was not charged, the order details page stated as such for the customer service representative. The customer service representative then retried the card with the gateway, and the card was approved. The customer never saw any error.

Now imagine that the On Error Resume Next statement was not in use. In that case, the customer would be stuck with either a generic error page or a detailed code error the customer doesn't understand. Not only that, the standard error message page doesn't look anything like the ecommerce website. It would have looked unprofessional and the customer would have to call to check and see if the order went through. The problem is that customers would probably reconsider whether to do business with your company if they see any error like that during the ordering process. Can they trust their credit card details with you if your application is generating errors? On top of that, it could be afterhours and the customer would have to call back the next day. At minimum, it would either be a loss of a customer to the business, or an inconvenience to the customer that the order couldn't be placed online.'

Now lets say that this ecommerce website was witten in C#. With a Try-catch block it could work if done properly but it would end badly if you didn't expect something odd to occur. If you use one Try-Catch block for your code and the connection to the gateway is in the same block as the 'save order' code line, then the error would have skipped the call to save the order. Since you got an error message, you could call the customer and see if he/she still wants to put it through but this doesn't look as good. It's also an inconvenience and could delay delivery. The right way to implement this section of the code would be to put the gateway connection in its own Try-Catch block. That way, the rest of your code is not skipped.

Unfortunately, sometimes a completely unexpected error is generated where you did not isolate a line with a Try-catch. In those cases, you will have to make your corrections to the code afterwards. It is in those scenarios that the On Error Resume Next advantage becomes apparent and sometimes these errors do occur. Visitors and website crawlers/hackers post data to your site that is not expected. In most cases, the error is small and doesn't warrant a complete failure. Take for instance if a NullReference exception occurs because a field on the order was missing or an error because of an illegal character in a field. Would it be better to let the site result in an order failure? Or, would it be better to have the customer representative contact the customer for the missing field (presuming it's necessary which might not be the case)? From a business perspective, the latter scenario is better.

It's like driving your car on the highway and pulling over to the side because there's a nail in your tire resulting in an air leak. You are better off driving to the auto shop and not letting a small inconvenience cause a larger problem. C# has its advantages, but the lack of a feature like VB's On Error Resume Next is not one of them. The Try-catch statement tends to clutter the rest of your code and the extra time it takes is money.

Visual Studio
Microsoft IIS
SQL Server
Windows Script Host
MS DNS Server
Microsoft FTP
Filezilla Server
Visual Basic

Tel: 720-383-4246
Tel: 678-739-9423