Menu
There are lots of places where guidelines for designing exception classes can be found. Almost everywhere I look, there's this list of things exception objects should never do, which impacts the design of those classes.
For instance, the Boost people recommend that the class contain no std::string members, because their constructor could throw, which would cause the run-time to terminate the program immediately.
Now, it seems to me that this is rather theoretical. If std::string's constructor throws, it's either a bug (I passed a null-pointer in) or an out-of-memory condition (correct me if I'm wrong here). Since I'm on a desktop, I just pretend I have an infinite amount of memory, and running out of memory is fatal to my application no matter what.
With that in mind, why shouldn't I embed std::string objects in my exception classes? In fact, why couldn't my exception classes be full-featured, and also take care of logging, stack tracing, etc. I'm aware of the one-responsibility principle, and it seems to me to be a fair trade-off to have the exception class do all that. Surely, if my parser needs to report a syntax error, an full-featured exception would be more helpful than an exception built around a statically allocated character array.
So: lean C++ exception classes - how big a deal is it in the real-world? What are the trade-offs? Are there good discussions on the topic?
874
Here you will learn about the built-in exception classes in C#. C# .NET includes built-in exception classes for every possible error. The Exception class is the base class of all the exception classes. The following is a hierarchy of exception classes in .NET:
The SystemException class is the base class for all the built-in exception classes in .NET Framework.
An unhandled exception may cause unexpected behavior, and results can be spectacular. Over time, these errors have contributed to the impression that exceptions are bad. But exceptions are a fundamental element of modern programming. Rather than fearing exceptions, we should embrace them and learn how to benefit from them.
There are many cases where a clear place exists to handle the exception internally, but there are many other cases where exposing the exception is better. So before you opt into handling the exception, just give it a second thought. A good rule of thumb is to only insist on handling exceptions when you are interacting directly with the end-user.
You could use the Boost.Exception library to help define your exception hierarchy. The Boost.Exception library supports the:
transporting of arbitrary data to the catch site, which is otherwise tricky due to the no-throw requirements (15.5.1) for exception types.
The limitations of the framework will provide you with reasonably defined design parameters.
Boost.Exception
See also: Boost.System
133
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
