Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
If you were going to do that, you don't want to catch(Exception ex) { throw ex; } - instead just catch { throw; } –  Steve Evers Oct 26 '10 at 16:40
Lets not forget about finally blocks ? –  Chris Oct 26 '10 at 16:42
+1 for mentioning about finally –  Kanini Oct 26 '10 at 16:48
You should specify the language in the tags. You're getting into more detail than is common to most implementations of exceptions, and ignoring things outside the blocks. In C++, for example, the most important part of exception handling is knowing how to write exception-safe programs. –  David Thornley Oct 26 '10 at 20:42
..and now with a rep giveaway, gentlemen ;) –  mlvljr Nov 1 '10 at 10:33

12 Answers 12

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.

share|improve this answer
+1 for the stack trace erasure issue. –  rwong Oct 27 '10 at 5:31
+1 for "... since it doesn't actually handle anything", people new to exception handling so often think catching means handling and don't realize if you don't do something to repair the problem, it's not exception handling, just code bloat. –  Jimmy Hoffa Oct 26 '12 at 20:41

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.

share|improve this answer
+1 for the teaching practice of leading them in the traditional C style return codes and error numbers and showing them that it works poorly and therefore, teaching them how it will work is a brilliant! –  Kanini Nov 2 '10 at 7:47
@Kanini: In general I think most relatively new/high level constructs seem like solutions in search of problems and are easy to use wrong if you don't understand what problem they were meant to solve and why they were invented. –  dsimcha Nov 2 '10 at 17:02
I agree that showing how it would be done without exceptions is good, but then comes the burden of explaining when to use exceptions and when to use other technics (because not all situations are exceptional) –  Matthieu M. Nov 4 '10 at 18:50
@Matthieu: Right. But if you understand what historical problems exceptions are meant to solve, rather than learning about them in a vacuum, it becomes more obvious that it's silly to use them for non-exceptional situations. –  dsimcha Nov 4 '10 at 18:56
right, that's why you got my +1. I just felt your answer could be interpreted as "never use another mechanism" :) –  Matthieu M. Nov 4 '10 at 19:01

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

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")) 

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

share|improve this answer
Fix: Thanks! But is it even right to have this exception block in the Data Layer? Should the whole thing of checking if the File is Available or Not not be in Business Layer? Otherwise, I do agree to your method of writing the code. –  Kanini Oct 28 '10 at 4:40
+1 for MSDN Design Guidelines. By far, the best IMHO. –  Kanini Oct 28 '10 at 5:41
Fix: In my native language, Kanini means a Computer whereas Kani means a fruit ;-) –  Kanini Nov 2 '10 at 4:30
I can tell you're not too upset by my error, but I am very sorry and I have corrected it. –  Conrad Frix Nov 2 '10 at 5:06
Fix: Upset? Not at all. Largely amused. My brother has not stopped laughing since I pointed this out to him primarily because, I do not resemble a fruit in anyway except maybe for the odd-shape... –  Kanini Nov 2 '10 at 7:52

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.

share|improve this answer
+1 for the role play idea. We never thought of it earlier. Whoever could have thought teaching programming could be done through Role Play? –  Kanini Nov 3 '10 at 1:55

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
share|improve this answer
+1 for the parent-child relationship example. –  Kanini Oct 26 '10 at 17:02

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.

share|improve this answer
@denny: While I agree with the "exception handling only will react when an error (or exception) occurs", I am quite not sure about the statement that "exception handling and flow control statements are basically the same". I respectfully disagree there. The catch block admittedly does what it should do under that condition. The try block however is not at all about flow or control. The finally block, again is not at all about flow or control. Maybe, I misunderstood your answer, but can you clarify for the benefit of me and others? –  Kanini Nov 2 '10 at 7:46

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.

share|improve this answer
Sounds like a plan. Do you have any sample code available in the Internet (say, sourceforge.net) that you would recommend? –  Kanini Nov 3 '10 at 1:52

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.

share|improve this answer
-1 for being too elitist and cs'y ;) –  mlvljr Nov 14 '10 at 12:05

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.

share|improve this answer
Monkeys? I suppose, your business users never heard that ;-) –  Kanini Nov 7 '10 at 3:00
@Kanini - Good one. That was in my Marine Corps days. I just wanted my guys to think outside the box when it came to error trapping. Did I just say error trapping... I meant exception handling. –  Cape Cod Gunny Nov 7 '10 at 10:59

Try : Head First Java [chapter 11]

I learned exception handling from this book [chapter 11] and it's the best way of teaching someone exception handling. I would strongly recommend this to everyone who want to learn exception handling. Just go through this chapter, it won't take more than 20 minutes to finish and you won't regret after reading that. Trust me.

share|improve this answer
Or a similar chapter in Head First C# –  Kanini Nov 9 '10 at 6:43

Why use exceptions?

  1. Exceptions allow you to easily re-use a single block of error-handling code for multiple error conditions.

  2. Exceptions allow you to reclaim the use of return values for output, instead of using return values exclusively for status code (success/failure) reporting.

  3. Exceptions allow your code to more easily propagate errors to the code which is best suited to make decisions about how to react to the error.

  4. Exceptions bring the expressive power of class taxonomy to error handling.

share|improve this answer
Um, er...Thanks! But the question is not Why use Exceptions. It is more about How to teach Exception Handling to a Newbie Programmer. –  Kanini Nov 3 '10 at 6:47
I find that students pay more attention when the subject has been motivated. Too often we teach the how, without the why. –  Mike Clark Nov 3 '10 at 7:08

For the ASP.NET part (your example case), point them to Robust ASP.NET Exception Handling book (60-page download, $7).

And as for the Java part, to Robust Java: Exception Handling, Testing, and Debugging and Java Exception Handling (another book with an alike name).

share|improve this answer
-2 now, are you guys nuts?? [yes, I'll be leaving these comments until the next passing by programming god explains why the heck this is a bad answer, esp. given it's freaking complete sources-wise (and thus, damn you, quite to the point! :))] –  mlvljr Oct 22 '13 at 0:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.