asmjit::ErrorHandler Class Reference [¶]
Error handler can be used to override the default behavior of error handling.
It's available to all classes that inherit BaseEmitter
. Override ErrorHandler::handle_error() to implement your own error handler.
The following use-cases are supported:
- Record the error and continue code generation. This is the simplest approach that can be used to at least log possible errors.
- Throw an exception. AsmJit doesn't use exceptions and is completely exception-safe, but it's perfectly legal to throw an exception from the error handler.
- Use plain old C's
setjmp()
andlongjmp()
. Asmjit always puts Assembler, Builder and Compiler to a consistent state before calling handle_error(), solongjmp()
can be used without issues to cancel the code generation if an error occurred. This method can be used if exception handling in your project is turned off and you still want some comfort. In most cases it should be safe as AsmJit uses Arena allocator and the ownership of allocated memory it allocates always ends with the instance that allocated it. If using this approach please never jump outside the life-time of CodeHolder and BaseEmitter.
ErrorHandler can be attached to CodeHolder or BaseEmitter, which has a priority. The example below uses error handler that just prints the error, but lets AsmJit continue:
If error happens during instruction emitting / encoding the assembler behaves transactionally - the output buffer won't advance if encoding failed, thus either a fully encoded instruction or nothing is emitted. The error handling shown above is useful, but it's still not the best way of dealing with errors in AsmJit. The following example shows how to use exception handling to handle errors in a more C++ way:
If C++ exceptions are not what you like or your project turns off them completely there is still a way of reducing the error handling to a minimum by using a standard setjmp/longjmp approach. AsmJit is exception-safe and cleans up everything before calling the ErrorHandler, so any approach is safe. You can simply jump from the error handler without causing any side-effects or memory leaks. The following example demonstrates how it could be done: