How to teach Exception Handling for New Programmers?

Question

How do you go about teaching Exception Handling to Programmers. All other things are taught easily - Data Structures, ASP.NET, WinForms, WPF, WCF - you name it, everything can be taught easily.

With Exception Handling, teaching them try-catch-finally is just the syntactic nature of Exception Handling.

What should be taught however is - What part of your code do you put in the try block? What do you do in the catch block?

Let me illustrate it with an example.

You are working on a Windows Forms Project (a small utility) and you have designed it as below with 3 different projects.

1. UILayer
2. BusinessLayer
3. DataLayer

If an Exception (let us say of loading an XDocument throws an exception) is raised at DataLayer (the UILayer calls BusinessLayer which in turns calls the DataLayer), do you just do the following

//In DataLayer
try {
    XDocument xd_XmlDocument = XDocument.Load("systems.xml");
} 
catch(Exception ex)
{
    throw ex;
}

which gets thrown again in the BusinessLayer and which is caught in UILayer where I write it to the log file?

Is this how you go about Exception Handling?

Answer 1

To explain exception handling, explain the concept behind it: The code where an error occurs frequently does not know how to properly handle that error. The code that knows how to handle it properly could be the function that called that one, or it could be further up the call stack.

When you write a routine that calls a routine that might throw an exception, if you know how to handle that error correctly, put the call in a try block and put the error-handling code in the catch block. If not, leave it alone and let something above you in the call stack handle the error.

Saying "catch ex, throw ex" is not a good way to do exception handling, since it doesn't actually handle anything. Plus, depending on how the exception model in your language works, that can actually be harmful if it clears stack trace information that you could have used to debug the issue. Just let the exception propagate up the call stack until it hits a routine that knows how to handle it.

Answer 2

Like most things, exceptions and exception handling will likely seem like a solution in search of a problem to new programmers until you show why the seemingly simpler solution (C-style return codes and errno) works so poorly. I would start out by motivating the problem and putting it in context. Show how error handling could be done using return codes or global/static variables. Then give examples of why it doesn't work well. Then and only then, introduce exceptions and explain that they're a form of out-of-band signaling and that the whole point is that the default behavior if you ignore an exception is to pass the buck up the call stack to someone who can handle it.

Bottom line: Showing how error handling was done in C will make the students understand what exceptions are really for and why catching exceptions that you can't really handle is basically simulating the way things were done in the Dark Ages.

Answer 3

I would start with Design Guidelines for Exceptions its short and includes DO, DO NOT and AVOID. It also gives the reasons why.

In your example case the revelvent section would be Wrapping Exceptions

And would expect it to be written this way. Note that it catches a specific exception and attempts to add information so that a more meaningful message is propagated. Also note that the inner exception is still maintained for logging purposes

//In DataLayer

try
{
XDocument xd_XmlDocument = XDocument.Load("systems.xml");
}
catch(FileNotFoundException ex)
{
        throw new TransactionFileMissingException(
                     "Cannot Access System Information",ex);
}

UPDATE Kanini asks is it even right to have this exception block in the Data Layer or should the checking the file be available to Business Layer.

Well first I'd like to point out that the rationale for Wrapping Exceptions is this

Consider wrapping specific exceptions thrown from a lower layer in a more appropriate exception, if the lower layer exception does not make sense in the context of the higher-layer operation.

So if you feel that have a higher layer should know about the file at all then your data layer should look like this

//In DataLayer

XDocument xd_XmlDocument = XDocument.Load("systems.xml");

No Try No Catch.

Personally I feel that unless your data layer can do something usefull like use a default systems.xml that is an assembly resource, doing nothing or wrapping the exception is a good bet since your logging will tell you what method and what file was the problem. (throw ex in this case or the preferred throw does too but adds no value). This means that once identified you'll be able to fix the problem quickly.

As an asside this particular example also has the following problem in that XDocument.Load can throw four execeptions

• ArgumentNullException
• SecurityException
• FileNotFoundException
• UriFormatException

We cannot safely guarantee that the following code won't throw and FileNotFoundException, simply because it could be there when we do existence check and gone when we do load. Having that available to the business layer would not help.

 if (File.Exists("systems.xml")) 
     XDocument.Load("systems.xml");

SecurityException is even worse because among other reasons for this being thrown if another process grabs has an exclusive file lock you'll won't get the error until you try an open it for reading because there's no File.CanIOpenThis() method. And if such a method existed you still have the same problem as with File.Exists

Answer 4

Lets do a role play. (this is not a joke post)

You should do a workshop where you act out the call chain. Each person is an object. You'll need some newbies and some people who understand the "game" helps.

Use a really simple issue like file IO. gui->model->file_io

The person being the file reader needs to tell the next one up....

First do it with return codes. ( use post-it notes ?)

if the interactions are just "what the code says" pretty soon you can get people to realize that exceptions are exceptional.

for return codes, pass a post-it note.

for exceptions, throw your hands in the air and say what the problem is.

then get them to do "catch x, throw x" and see ho much worse the diagnosis is what the GUI just gets "the model had an exception".

I think this will work to train the people you have because people understand interactions with other people pretty well.

Answer 5

I would imagine to understand exceptions you first need to understand the child/parent relationship of classes for example. If you understand that a child can inherit functionality from a parent, they might be able to on an elementary level understand that if a child has a problem it cannot handle it will pass this problem (exception) up to its parent and let the parent deal with it.

This becomes a chained relation until you end up with a place where something knows how to handle the exception.

And as far as finally goes this is the trivial part... when a problem occurs something has to handle it so the program does not exit fatally, after that exception is handled the finally block is there which will always execute regardless of the try catch.

A good example of this might be with networking:

• we make connection
• connection is ok so we use it
• when finished we close up and free resources

or in exception case:

• make a connection
• an exception occurs which something handles
• at whichi point we free up connection and resources associated

Answer 6

Give an Application to the newbie which has very good Exception handling in it. Throw some exception somewhere and let them debug it with the help of Logs. By tracking the propogation of Exception they should be able to debug it. Do this exercise 3 or 4 times. Now just remove all the Exception handling from the code and let them try to track the same exception.

I believe the appreciation for the Exception Handling code will be instantly appreciated.

Answer 7

IMO, you should think that exception handling and flow control statements are basically the same. You use them to control the flow of your programs based on what condition they are currently in. The difference is exception handling only will react when an error (or exception) occurs.

Answer 8

It probably wouldn't help a new programmer, but I found that I understood the concept of exceptions a lot better once I started using monads in functional programming. A monad forces you to consider every "channel" through which data can travel into or out of a program, since all it does it provide a convenient abstraction to "hide" some of that data flow.

The idea that a function can have different types of output, and an exception is like a higher-priority type of return from the function is pretty neat.

Mind you, I understand that isn't how exceptions work in most language (implementation details), but in an abstract sense, that's what is happening.

Answer 9

Pretend a monkey is using the keyboard

I used to tell my guys when they are writing code to pretend that a monkey will be sitting at the keyborad and using this application.

This taught them how to anticipate all kinds of things:

• Missing data
• Missing files
• Alpha characters when you expect numbers
• Division by zero

I think it was the word picture of having a monkey just banging keys and doing whatever it wanted instead of following along nicely that did the trick. It worked for me.