It looks like I'm obsessed with error management and exceptions.

Well, having dealed with both applications that use the "old style" error code and the ones that uses exceptions, I've learned to appreciate the seconds, when well done.

Weird stuff

Nobody likes to deal with errors: they break the natural flow of your source code, they can crash your application, and your customers notice them before you do.

But the DO happen, so we better deal with them.

Until the exceptions were introduced, a classic way to deal with errors was to check for the return value of the called methods, or to call some kind of "GetLastError" function once in a while.

Legacy rulz

Some programmers love to deal with functions that return an error code, and they loves to call GetLastError() once in a while, usually because they can avoid to check for error codes and call GetLastError() at all. When they use exceptions they are forced to insert a lot of catch(...) statements to catch and ignore exceptions.

Some of them don't love error codes and GetLastError() kind of stuff but they hate exceptions, so they stick with the old school method.

Exceptions rulz

Exceptions are cool, when something goes wrong you just have to throw an exception. No more checking for error codes, no more uncool calls to GetLastError(), no more interferences with the natural flow of the code: all the "if(error) then do this otherwise do that" can disappear and we can finally appreciate a straightforward sequence of operations.

Or not?

Well, to start appreciating the exceptions you have to learn to live with them:

• everything you allocate must be able to deallocate itself automatically. Easy with garbage collectors, easy also in C++ if you know how to do it (start looking for auto_ptr in the standard library, or shared_ptr in boost).
• now exceptions are part of your application and your design should consider them too: you should plan their hierarchy and their behaviour

For instance, if your code allocates an handle, you must be sure that the handle will be released when it isn't needed anymore; you should write a class that takes care of that handle and releases it in the destructor.
A classical example are the Device Context Objects in Windows (pens, fonts, and so on): if you forget to release some of them you end up with an application that will be unusable few minutes after it has been launched.

Writing code that releases automatically the handles and resources is good also if you don't plan to use exceptions: multiple return point can be used without worries (yes, I like multile return points too), and in general you end up with much less memory and handles leaks.

Somebody said that exceptions are slow...

...and they prefer C to C++ because they say it is more efficient.

Not everything that is new is also slow: if you made the step from C to C++, then you can make one more step and start using exceptions. I've seen exceptions in a wide range of applications, and they NEVER were the cause for poor performances: if your application run slower, usually the last place you have to look for are the exceptions handlers.

Let's fart

Exceptions are like noisy farts: you notice them immediately, and most of the time you can tell who thrown it. If you forget to handle an exception, it will crash your application. Period.

Error codes and GetLastError() are like a silent fart: you can ignore it and everything seems normal until is too late to do something about it. And it is difficult to find the perpetrator.

This is just another reason to switch to exceptions: I prefer an honest noisy fart, I prefer the guy that raises its hand and says "Sorry, it was me", and then everybody laugh.

You will learn to love it when your application will just crash in front of you instead of giving you a wonderful, nicely formatted, shiny result, completly wrong, because of one GetLastError you forgot to call for the 1000th time.

---

Bookmark this