libcult/documentation/eh

The libcult exception handling library defines a base +exception type to be used by the rest of libcult. It has +a very basic interface:

+ +

+namespace Cult
+{
+  namespace EH
+  {
+    class Exception: public virtual std::exception
+    {
+    public:
+      virtual char const*
+      what () const throw ();
+    };
+  }
+}
+

+ +

It derives from std::exception to allow catching +all exceptions with a single handler. Default implementation of the +what() member function returns type-name of the exception. +

+ +

Every non-trivial library in libcult derives its own +base exception which all library-defined exceptions inherit. This +way you can catch all exceptions from a library with one handler.

+ +

Sometimes it may seem convenient to further partition (by providing +corresponding base classes) exceptions space into logic +exceptions (shared by all implementations) and implementation +exceptions. For example, if you pass an allocator illegal size 0 then +the allocator throws an exception which can be classified as a logic +exception. If, however, you passed valid size but there is not enough +memory then the allocator throws an exception which can be classified +as an implementation exception¹.

+ +

The problem with this approach lies in the fact that someone's logic +exception is someone else's implementation exception. Consider, for +instance, a buffer type that is implemented in terms of our allocator. +If the buffer happened to request a memory block of size 0 and let +the exception propagate through the interface boundaries it is no longer +a logic exception.

+ + +

¹ It can be argued that the +NoMemory exception should rather be classified +as logic. However, let's assume there are allocator implementations +that have infinite memory.

+ +