#include <archon/util/exception.H>
Inheritance diagram for Archon::Utilities::Exception:
Public Types | |
typedef string(* | Formatter )(const type_info &type, string location, string message) |
typedef bool(* | InfoCatcher )(Formatter, string &) |
Public Member Functions | |
virtual | ~Exception () throw () |
string | getLocation () |
virtual string | getMessage () const throw () |
Static Public Member Functions | |
template<InfoCatcher C> | |
static void | terminal () |
This template function is intented to be installed directly as the 'unexpected handler' and the 'terminate_handler'. | |
static string | explainLong (const type_info &, string location, string message) |
Generate a possibly multi-lined message describing an exception. | |
static string | explainLongUnknown () |
Generate a possibly multi-lined message describing that an exception is unknown. | |
static string | explainShort (const type_info &, string location, string message) |
Generate a short one-lined message describing an exception. | |
static string | explainShortUnknown () |
Generate a short one-lined message describing that an exception is unknown. | |
static string | line (long) |
Support method for the ARCHON_THROW macro. | |
Protected Member Functions | |
Exception () | |
Exception (string location) | |
Exception (string location, string message) |
To achive a good utilization of the throw-specification in functions and method signatures, the notion of "unexpected exceptions" has been adobted. Unexpected exceptions are those exceptions that should not be declared in the throw-specification. To some extent they resemble the RuntimeException in Java.
The goal is to get as much usefull information into the throw-specification as possible. Adding every possible exception to the throw-specification would clutter the code badly. Fortunately, in practical programming many (or even most) of the thrown exceptions are unexpected exceptions. Thus, it becomes reasonable to recommend that all exceptions that are not unexpected exceptions be declared in the throw-specification of function and method signatures.
An UnexpectedException subclass has been provided as a super-class of all unexpected exceptions to aid in the cases where a method or function can throw both "ordinary" and unexpected exceptions. Thus, instead of having to add a large number of unexpected exception types to the throw-specification, you can simply can add UnexpectedException.
Adding UnexpectedException will ensure that the unexpected exceptions can propagate upwards for the rare cases where an application wants to catch them. If you do not add UnexpectedException, the unexpected exceptions will be diverted to the global unexpected handler which must terminate the program.
To recap, the introduction of UnexpectedException has made it feasable to add a throw-specification to each and every function as well as method whithout increasing the involvement of the global unexpected handler.
std::set_unexpected
Definition at line 109 of file exception.H.
|
Definition at line 126 of file exception.H. |
|
Generate a possibly multi-lined message describing an exception. It may be used as an argument to Exception::catchInfo. This1 is exactly what Exception::terminal does.
Definition at line 47 of file exception.C. References Archon::Utilities::cxxDemangle(). Referenced by terminal(). |
|
Generate a possibly multi-lined message describing that an exception is unknown. This method is used by Exception::terminal.
Definition at line 63 of file exception.C. Referenced by terminal(). |
|
Generate a short one-lined message describing an exception. It may be used as an argument to Exception::catchInfo.
Definition at line 75 of file exception.C. References Archon::Utilities::cxxDemangle(). Referenced by Archon::X3D::SAI::exceptionCatchShortExplanation(), and Archon::X3D::Proxy::exceptionCatchShortExplanation(). |
|
This template function is intented to be installed directly as the 'unexpected handler' and the 'terminate_handler'. All it does is write the available details to cerr. If you use it, you must specify an info catcher function as a template argument. Archon::Utilities provide you with a basic one, exceptionCatchInfo. Example:
using namespace Archon::Utilities;
int main(int argc, const char *argv[]) throw() { set_unexpected(Exception::terminal<exceptionCatchInfo>); set_terminate(Exception::terminal<exceptionCatchInfo>); ... }
This info catcher function provided by Archon::Utilities is sufficient if all your exceptions derive from Archon::Utilities::Exception and all relevant exception information is available through this base class. If your application uses SomeCoolLib as well as Archon::Utilities and SomeCoolLib provides an info catcher function that is aware of exceptions from Archon::Utilities, you should substitute exceptionCatchInfo with SomeCoolLib::exceptionCatchInfo. If SomeCoolLib is unaware of exceptions from Archon::Utilities (or you do not know about it) you must write your own info catcher function function and then substitute exceptionCatchInfo with MyApp::exceptionCatchInfo. See exceptionCatchInfo for an example of this.
Definition at line 172 of file exception.H. References explainLong(), and explainLongUnknown(). |