9: Some Exceptional Exceptions in C#.NET

Generating ANSI/AIM Code 39 in C#.NET 9: Some Exceptional Exceptions

Handling errors via return codes Using the exception mechanism instead of return codes Plotting your exception-handling strategy

know it s difficult to accept, but occasionally a method doesn t do what it s supposed to do Even the ones I write especially the ones I write don t always do what they re supposed to Users are notoriously unreliable as well No sooner do you ask for an int than a user inputs a double Sometimes, the method goes merrily along, blissfully ignorant that it is spewing out garbage However, good programmers write their methods to anticipate problems and report them as they occur I m talking about runtime errors, not compile-time errors, which C# spits out when you try to build your program Runtime errors occur when the program is running, not at compile time The C# exception mechanism is a means for reporting these errors in a way that the calling method can best understand and use to handle the problem This mechanism has a lot of advantages over the ways that programmers handled errors in the, uh, good old days Let s revisit yesteryear so that you can see This chapter walks you through the fundamentals of exception handling You have a lot to digest here, so lean back in your old, beat-up recliner

C# introduces a completely different mechanism for capturing and handling errors: the exception This mechanism is based on the keywords try, catch, throw, and finally In outline form, it works like this: A method will try to execute a piece of code If the code detects a problem, it will throw an error indication, which your code can catch, and no matter what happens, it finally executes a special block of code at the end, as shown in this snippet:

public class MyClass { public void SomeMethod() { // Set up to catch an error try { // Call a method or do something that could throw an exception SomeOtherMethod(); // make whatever other calls you want } catch(Exception e) { // Control passes here in the event of an error anywhere // within the try block // The Exception object e describes the error in detail } finally { // Clean up here: close files, release resources, etc // This block runs even if an exception was caught } } public void SomeOtherMethod() { // error occurs somewhere within this method // and the exception bubbles up the call chain throw new Exception( Description of error ); // method continues if throw didn t happen } }

The combination of try, catch, and (possibly) finally is an exception handler The SomeMethod() method surrounds a section of code in a block labeled with the keyword try Any method called within that block (or any method that it calls or on up the tree ) is considered to be within the try block If you have a try block, you must have either a catch block or a finally block, or both A variable declared inside a try, catch, or finally block isn t accessible from outside the block If you need access, declare the variable outside, before the block:

int aVariable; // Declare aVariable outside the block try { aVariable = 1; // Declare aString inside the block string aString = aVariableToString(); // Use aVariable in block } // aVariable is visible here; aString is not

Think of using the try block as putting the C# runtime on alert If an exception pops up while executing any code within this block, hang a lantern in the old church tower (one if by land, two if by sea or, call 911) Then, if any line of code in the try block throws an exception or if any method called within that method throws an exception, or any method called by those methods does, and so on try to catch it Potentially, a try block may cover a lot of code, including all methods called by its contents Exceptions can percolate up (sometimes a long way) from the depths of the execution tree I show you examples