Once you have caught an exception, most code will simply tidy up any loose resources (to prevent leaks), and rethrow the exception up to a higher layer handler.
At the top level of the program, clearly this is not an option. The catch clause needs to return the error using whatever process the calling program is using for error handling.
Details of the message from the caught error can be read (from inside the fz_catch block) using:
The error will remain readable in this way until the next use of fz_try/fz_catch on that same context.
Some code may choose to swallow the error and retry the same code again in a different manner. To facilitate this, we can find out the type of error using:
See section 6.2 Throwing exceptions for a list of the possible exception types.
For example, if an exception was thrown whilst attempting to render a page to a full page bitmap, it is entirely possible that this might be due to running out of memory. An application might reasonably decide to retry the render doing a strip at a time.
If, however, the render failed because of a corrupt file we’d gain nothing by retrying - hence the application should check the type of the exception to ensure it was a FZ_ERROR_MEMORY before trying the alternative technique.
To simplify the job of deciding whether to pass on exceptions of a given type, we have a convenience function that with rethrow just a particular type: