TinmanException
Description
- Derived from
- Extended by
-
ConfigException sealed
FailedAssertionException sealed
GeorefException sealed
InvalidArgumentException sealed
IOException sealed
LicenceException sealed
PoolingException sealed
RenderException sealed
ValidatingException sealed
This is the base exception class of the Tinman Library.
When an instance of TinmanException (and not one of its subclasses) is thrown, this means that an unexpected error has occurred. An application may catch such errors and try to continue, consuming the provided error information, for example by creating a problem report.
Subclasses of TinmanException are used to distinguish between error types that an application can respond to by catching specific exception types only. Low-level error information is provided using TinmanError objects. Subclasses may also provide additional error information, on a higher application level.
The following exceptions are thrown in DEBUG mode only and indicate programming mistakes. These exceptions are not included in the list of thrown exceptions in the documentation of a method; instead, the preconditions and assertions are explained.
-
InvalidArgumentException
Some method arguments do not satisfy the methods preconditions. -
FailedAssertionException
The called method is not valid for the current state of the object.
These exceptions represent expected error situations which are thrown in both DEBUG and RELEASE mode (dependent libraries may define additional exception types):
-
ConfigException
An error related to the use of the Config API has occurred (e.g. bad syntax, bad semantic, etc.). -
IOException
An input / output error has occurred (e.g. accessing the filesystem, the web, etc.). -
PoolingException
A pooled background task has failed. -
ValidatingException
High-level validation has reported one or more errors.
Panic situations (i.e. fatal internal errors) are reported via Panic. Obviously, this should never happen. But if it does anyway, the reported information can be used to file a bug report (please send to: support@tinman3d.com). Information may be found in log output (see LoggingUtil), in error dump file (see TinmanErrorDump) or exception messages.
Public / Constructors
NativeError
3 overloads
A native function call has failed although it was expected to succeed.
The error code is retrieved via FetchLastError.
- See also
A native function call has failed although it was expected to succeed.
- See also
A native function call has failed although it was expected to succeed.
- See also
Public / Methods
NativeErrorMessage
3 overloads
Generates an error message for NativeError1.
Generates an error message for NativeError2.
Generates an error message for NativeError3.
Panic
A panic situation has occurred.
A panic is an unrecoverable problem usually caused by programming errors at development time that are reported by throwing an exception in DEBUG mode. In RELEASE mode, panic handling is platform dependent, to allow more aggressive code optimizations (e.g. noexcept
in C++):
-
C# / RELEASE :
A TinmanException is thrown. -
C++ / RELEASE :
std::terminate
is called.
For the RELEASE mode case, dummy code is in place to make the compiler happy. Dummy code should be as simple as possible, for example a single return
or use of default values. It is assumed that dummy code will never be executed.
- See also
Panic_ShouldNeverHappen
This code path will never be executed; static code analysis may fail to detect this, but the developer (hopefully) knows better.
This factory method is only used to satisfy coding guidelines and to make the compiler happy.
Panic_UnknownEnum
2 overloads
A panic situation has occurred (unknown enum item).
- See also
A panic situation has occurred (unknown enum item).
- See also
PanicHandler
Optionally, a panic handler may be specified which will be called in a panic situation, instead of performing the default behaviour as described for Panic.