I recently read Vadim Kokielov's article on Windows' SEH, but I think that there were some unfair, and perhaps hasty, conclusions reached in the comparison of Windows' SEH with C++ EH. My article is intended to be a rebuttal and is provided merely for additional insight into the topic of C++ EH. It is not intended to be completely unbiased.
If anyone can correct me on these arguments and suggestions (particularly Vadim) I would appreciate it and post the conclusions as updates here, or perhaps as a part 2 of this article, if the GDnet staff is willing to format it (Ed.- we are). Please do not post a reply intended for me on the GDNet message boards.
Any email I get containing any of the following: violent replies, wild assumptions, and any arguments related to C vs. C++ or OOP vs. Structured Programming will be deallocated immediately
and no credit will be given to the author of such crap in the event that he/she manages to provide useful information.Onward to the rebuttal.
[size="5"]Termination Handlers
In comparison with C++ exception-handling, termination handlers really only matter for resources that will not be deallocated by destructors (i.e., temporary resources dynamically allocated by non-C++ code from inside a function, or from inside a constructor). In all other instances, a properly-written destructor will be able to clean it up.
For such special instances, one can easily write a class template that will take advantage of the destructor calls made when local variables go out of scope. It only has to be written once (per programmer lifetime
, plus a simple deallocator (in most cases, a single function call). I would remind you that although the deallocator has to be written (once per type, not per instance) and the template class instantiated in C++ EH, in SEH you would have to write the deallocation function calls in your __finally block anyway.[size="3"]Examples
The class template need only be a slightly modified version of std::auto_ptr. For example,
namespace auto
{
namespace deallocation
{
template
struct heap { void operator () (T* const pointer) { delete pointer; } };
struct handle { void operator () (HANDLE const handle) { CloseHandle(handle); } };
struct bitmap { void operator () (HBITMAP const handle) { DeleteObject(handle); } };
struct window { void operator () (HWND const handle) { DestroyWindow(handle); } };
struct file { void operator () (FILE* const handle) { _fclose(handle); } };
struct com_object { void operator () (IUnknown* const handle) { handle->Release(); } };
// etc.
};
template >
class handle
{
T* pointer;
D deallocate;
public:
handle(T* const pointer) : pointer(pointer) {}
~handle() { if( pointer ) deallocate(pointer); }
// ...
};
};void myclass::myclass(const char* const filename)
{
auto::handle bc = new some_big_class;
auto::handle fp = _fopen(filename, "r");
// bc and fp are automatically closed whether or not an exception is thrown
}[size="3"]Conclusion
This solution has the following benefits over SEH:
- Class destructors become analogous to the __finally blocks.
- Deallocation code (including its logic) only has to be written once per type, not per instance (as with SEH).
- The habit of declaring resources as having automatic deallocation is easier to obey than declaring them normally and then remembering to clean them up.
- The handle class is extensible in any way a normal C++ class is, while SEH must remain tied to structured programming (hence its name).
- C++ EH and auto::handle are portable across platforms; SEH is not.
[size="5"]Performance and Flexibility
[size="3"]Exception Filters
C++ directly supports exception filters, in the form of type-checking. Consider the following example.
[size="3"]Examples
// These "empty" types allow us to filter exceptions - typically defined elsewhere
struct exception {}; // anything
struct file_exception : public exception {}; // all file exceptions
struct eof : public file_exception {};
struct file_not_found : public file_exception {};
struct unsupported_seek : public file_exception {};
struct out_of_memory : public exception {};
// Function declarations for example
void do_something() throw( eof, file_not_found, unsupported_seek );
void do_something_else() throw( out_of_memory );
void some_complex_function()
{
try
{
do_something();
do_something_else();
}
catch( eof ) {} // catches end of file exceptions
catch( file_not_found ) {} // catches file not found exceptions
catch( file_exception ) {} // catches all other file exceptions
catch( exception ) {} // catches anything else
}C++ EH protects C++ from incorrectly handling code written by other people, since the unknown exception will simply keep unwinding the stack until it is either handled by someone who actually _knows_ the type, or the program ends.
With SEH, if two exception constants have the same value, it is possible for client code to throw an exception and your code to misinterpret it. Chances are that 100 years down the road, your grand children's X-Plus code will catch and interpret the exception differently than was intended. ;)
[size="3"]Performance
Although C++ EH is supposed to be slower than SEH, I do not understand why that matters in this comparison. EH is used to handle exceptional conditions, and is not intended to be used as a replacement for assertions, logging, or return values in time-critical code.
[size="3"]Simplicity
Curiously enough, this category was not introduced in the comparison. C++ EH requires 3 new keywords, while SEH requires that plus learning a new (small) API.
Any additional conditional logic needed to handle the exception (or simply rethrow it) can and should be written _inside_ the appropriate catch block. The C++ EH conditional logic is exactly the same as normal (i.e., if...else, etc.), while SEH depends on API functions and specialized code, and precludes the use of normal "flow of execution modifiers" unless you want to lose the performance "advantage."
[size="3"]Portability
C++ EH is portable across all platforms that support the C++ standard. SEH is portable across all languages that Windows supports and compiler-writers comply with. I prefer the former.
[size="5"]
Conclusion to the Rebuttal
If you use C++, then C++ EH is probably the better choice. Of course, that is coming from a C++ user, so it is immediately invalidated. ;) (j/k)
- null_pointer ([email="null_pointer_us@yahoo.com"]null_pointer_us@yahoo.com[/email])
