[cairo] cairomm exception handling questions

[Jonathon Jongsma]

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:

try {
   context->foo();
}
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.

-- 
jonner