Posts Tagged ‘Structured Exception Handling’

Structured Exception Handling in .NET Part 5: Throwing new Exceptions

Thursday, March 20th, 2008
This entry is part of a series, Structured Exception Handling in .NET»

As I mentioned earlier, throwing Exceptions can be a very useful way of notifying the appropriate code that something unexpected happened.  In order to throw an Exception, first you create an object of type Exception, or a class which inherits from Exception if there is a more appropriate one.  You should also set the Message property, which can usually be done from a constructor.  You can actually do all this in a single line.  eg.

Throw New Exception(“Invalid username”)

Some Exception classes will want additional data, depending on the type of Exception that you are notifying about.  It is worth looking around the .NET framework or any other set of code that you are using to see what Exceptions are available.  I will post up some common ones in a later post.

Structured Exception Handling in .NET Part 4: Re-Throwing Exceptions

Wednesday, March 19th, 2008
This entry is part of a series, Structured Exception Handling in .NET»

Sometimes when you have caught an Exception, you want to do a bit of processing and then throw the Exception on again, or perhaps check the Message property to decide if you can handle it, and if you can’t then you throw it again. This is actually quite easy – you just use Throw, with no parameters.

eg.

Try
   DoSomething()
Catch Ex as Exception
   If Ex.Message="Connection Failed"
      Conn.Reconnect()
   Else
      Throw
   End If
End Try

One thing that you really don’t want to do is to Throw Ex

Structured Exception Handling in .NET Part 3: The Exception Class

Tuesday, March 18th, 2008
This entry is part of a series, Structured Exception Handling in .NET»

The base .NET Exception class has several useful properties to retrieve data about what went happened: –

Message
This is probably the most used one.  It is simply a textual message explaining some detail about the exception.

InnerException
Sometimes you’ll find that some piece of code lower down the line has caught an exception and wanted to add some information itself, so what it does is to create a new Exception, and put the one that it caught into the InnerException property.  Sometimes you really need to access this in order to find out what happened, because the actual exception that you caught is very non-specific about what happened.  The other thing to bear in mind is that the InnerException can also have an InnerException and so on.

StackTrace
This returns a string that contains a stack trace that you can use to see how the code got to this point.  It can be very useful for debugging.

Source
This returns a string that tells you the name of what caused the error.  I usually don’t tend to find this particularly useful

TargetSite
This returns a reflection object representing the method that the exception occurred within.  I’ve not actually found any use for this yet, but I can see how it could be useful.

Data
This is a Dictionary of any extra pieces of information you might need to know about the Exception.

Structured Exception Handling in .NET Part 2: Multiple Catch Clauses and Different Exception Types

Monday, March 17th, 2008
This entry is part of a series, Structured Exception Handling in .NET»

Not everyone realises that you can have multiple Catch clauses per Try clause. The point in this is that you can catch different types of Exception.

You may have a function which can throw several different types of Exception. You can catch specific types of Exception separately and deal with each of them differently.

For example, you may wish to do something like this (nb. these Exception classes are made up – they aren’t in the .NET framework)…

Try
   DBConn.ExecQuery(Query)
Catch ex as ForeignKeyException 'inherits from KeyException
   MsgBox("Sorry -  this query would cause a conflict with another table")
Catch ex as KeyException
   MsgBox("Sorry - this data is not valid")
Catch ex as ConnectionException
   MsgBox("The database connection has gone down.  Please reconnect and try again")
Catch ex as Exception
   MsgBox("Something else went wrong - " &  ex.Message)
End Try

Note that catch clauses will catch any object of inherited Exception classes as well as the class that you specify, so if you need to catch a more specific type of Exception, you need to put it before a less specific type, which is why ForeignKeyException comes before KeyException, and everything comes before Exception.

Structured Exception Handling in .NET Part 1: Try/Catch/Finally

Thursday, March 13th, 2008
This entry is part of a series, Structured Exception Handling in .NET»

A friend has asked me to write some articles on how to handle exceptions in .NET, so here we go… A little bit of background first: –

Exceptions occur when things go wrong or other exceptional circumstances. They are a bit more complicated than the older error trapping systems, but the complexity lets you do a lot with them. Every Exception is an object, and it is either an object of type Exception, or of a type that inherits from Exception.

In this post, I’m just going to deal with catching a general Exception. I’ll cover what you can do with the Exception class itself, multiple Catch clauses, different Exception types, re-throwing and creating your own Exception classes in other posts.

So here is the way it works. When something goes wrong, an Exception object gets created and “thrown”. This means that the stack rewinds back until it finds something that catches the Exception. Basically, this means that anything that gets called inside a Try clause will be handled if an Exception gets thrown. Not only that, but any functions that that calls etc. on and on either forever or until there is another Try clause that will handle it. “Later” Try clauses take precedence over earlier ones.

This is how to use it…

Try
   Some code
Catch ex as Exception
   Some exception handling code
Finally
   Cleanup code that gets called whatever
End Try

Note that the Finally clause is actually optional – it is fine to leave it out. You would normally use it if you wanted to close a database connection, file, stream, network connection etc. or some other form of cleanup code. Also, you can have multiple Catch clauses, but I’ll cover that later.