Upcoming Events
Unite 2010
11/10 - 11/12 @ Montréal, Canada

GDC China
12/5 - 12/7 @ Shanghai, China

Asia Game Show 2010
12/24 - 12/27  

GDC 2011
2/28 - 3/4 @ San Francisco, CA

More events...
Quick Stats
65 people currently visiting GDNet.
2406 articles in the reference section.

Help us fight cancer!
Join SETI Team GDNet!
Link to us Events 4 Gamers
Intel sponsors gamedev.net search:

Contents
 Prelude
 What are
 Exceptions?

 Exception Safety
 and Error Handling

 Exception Class
 Final Thoughts

 SmartTest.zip
 Exception.zip
 Printable version
 Discuss this article
 in the forums


Final Thoughts - Will this guy ever stop?

Yeah, yeah, soon enough. Let’s go through some more details before I sign off.

  1. Destructors cannot throw.
  2. Destructors are meant for cleaning up and should never throw. If you find you need to throw in a destructor, it’s best to redesign the class

  3. No setjmp/longjmp/goto allowed.
  4. This is probably for the better. If don’t know what I’m talking about, good for you and move along.

  5. Asynchronous Vs Synchronous exception handling.
  6. Under asynchronous EH (exception handling), the compiler assumes that any line can throw an exception. Under synchronous EH, the compiler only assumes exceptions occurred where the programmer specify the throw.

    What this means is that synchronous EH is more efficient for functions that don’t throw exceptions, since the compiler don’t generate code to keep track of the unwinding of the stack

    Maybe I’m paranoid, but I like to ensure that even my release programs are exception safe, so I prefer async EH to sync EH.

    As far as I can tell, sync EH might not be exception safe when a hardware exception occurs. If someone knows more about this, please enlighten me.

    In VC++ 5.0, async EH was the default. In VC++ 6.0, sync EH is the default.

    So if you want to enable async EH, look at the /EHa compiler flag.

  7. Performance of exceptions.
  8. Setting up a try/catch block does take some resources. In general, try to reduce the number of try/catch blocks. Exceptions are errors but errors are not necessarily exceptions. So if the error is a very predictable type of error, maybe a return code is more appropriate.

  9. Threads
  10. Each thread requires its own try/catch block. This would mean exceptions cannot propagate between threads. What this means is that the main thread needs some way to be notified when a spawned thread encounters an exception. I don’t know, maybe your main thread needs to monitor the state of all the threads continuously, and if any thread encounters an exception, the main thread tells all other threads to end and throws an exception.

    I have not found of an elegant solution with respect to threading yet. If you do have some tips, please share.

  11. Static Objects
  12. Since exceptions thrown require a try/catch block to handle the exception, a static object constructor should not throw. If you must throw, you probably have to set the unexpected handler in the first line of the constructor.

    Again, I have not found an elegant solution to this problem.

  13. Windows Quirks
  14. No doubt when coding with Windows and its old C code, you will come across many situtations requiring weird hacks.

    For example, in the WM_INITDIALOG message handler in a dialog wndproc, you need a try/catch block to make a call to EndDialog in case an exception occurs while creating the dialog.

    Also, when you display a MessageBox in the catch handler, you cannot pass it a NULL window handle or the program will crash when exceptions are thrown from the wndproc (certain messages).

    Just be on the lookout for weird stuff like this.

I hope I have presented some useful information about exceptions and how to write safe code. Now, please don’t write any programs that crash my system.