[cairo] cairomm exception handling questions
jonathon at quotidian.org
Mon Aug 11 11:11:12 PDT 2008
Ian Britten wrote:
> Hi all,
> Just a couple of elementary exception handling questions, related
> to cairomm. (I'm trying to get my groundwork laid correctly)
> - After some trial-and-error (And grubbing through the cairomm
> source code), I've discovered that passing an invalid file name
> to PdfSurface::create() doesn't throw a Cairo::logic_error
> exception, but instead, a std::ios_base::failure exception.
> Wouldn't it make it more consistent to throw all cairomm
> exceptions as Cairo::logic_error? Currently, I (as a programmer
> trying to trap all Cairo exceptions and downgrading them to
> errors) must add multiple 'catch' statements to all my 'try'
> statements. That seems like it'll get repetitive/tedious pretty
> quickly.. :(
Well, we tried to use the same exceptions that you would get from doing
similar things in the C++ standard library. I agree that this does not
look ideal for your use case. They do both inherit from std::exception,
so you could catch all of them using that, however you'd obviously be
limited to the std::exception interface in that case.
> - What am I expected to do with a Cairo::logic_error exception? I
> had been planning to try use the ErrorStatus (cairo_status_t) to
> return a meaningful error to the calling code. However, it seems
> that I can't access the status (private, no 'get'). Thus, it
> seems that all I can do is return a "Something went wrong in Cairo"
> error, from every 'catch' that I write...
This seems like an oversight. We could add a 'get' for the status code,
though that would only cover those exceptions that are represented by
the Cairo exception.
An alternative might be to query the Context or the Surface's status
inside the exception handler. For example, something like:
catch (const std::exception& ex)
/* use context->get_status() rather than the non-existent
ex.get_status() to determine the cause of the exception */
The get_status() functions are not advertised since the intent was to
use exceptions for error-handling rather than error statuses, though
obviously our implementation of exceptions seems to be slightly
incomplete at the moment.
More information about the cairo