[cairo] cairomm exception handling questions

[Ian Britten]

Murray Cumming wrote:

>> - 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.
> 
> As you can see in the implementation here:
> http://cgit.freedesktop.org/cairomm/tree/cairomm/private.cc
> this is the (indirectly) recommended exception for this cairo error:
> http://cairographics.org/manual/bindings-errors.html

Thanks (And to Jonathon too) - Very helpful.  I'm still new to Cairo,
and am still finding/reading documentation.

> But if we are wrong about that, changing the exceptions thrown would
> generally be an API and ABI break - applications that expected the
> existing exceptions would no longer work.

Ya, sorry - I wasn't necessarily suggesting changing it.  I was
mostly commenting on the perceived awkwardness, and wondering about
the reason/intent.

>>    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..  :(
> 
> Of course you shouldn't be catching the exceptions for every call.
> That's why they are exceptions.

Admittedly, my experience with exceptions is fairly limited.
However, as a library writer trying to add a Cairo 'canvas' to
our existing framework, I would think that I would want to catch
the exceptions, wouldn't I?  The higher-level code is certainly
NOT exception-safe, and I'm trying to ensure no exceptions(*)
propagate out.  [ Thoughts/Suggestions/Guidelines welcome ]

(*) Admittedly, exceptions like 'new' are a bit different, but I'm
mostly interested in the cairo-specific errors/problems that I
can fix/prevent/handle/etc.

> I think it's more important that we document what exceptions can be
> thrown by what methods. But to know that we need to know what errors can
> be set by what C functions and that's lacking from the cairo
> documentation currently. For instance:
> http://www.cairographics.org/manual/cairo-PDF-Surfaces.html#cairo-pdf-surface-create

I'm note sure that an exact listing of errors for each method/function
(And all the child calls) would be feasible - It'd certainly seem to
me to be tedious to maintain (And I don't think I'd want to do it!)

However, the information you indicated on that link seems adequate
for programming with.  I guess my problem was I had only looked at
http://www.cairographics.org/documentation/cairomm/reference/classCairo_1_1PdfSurface.html#92403fe5ad8ae6862e005c3d185e9123
which doesn't give any information about errors.
Since it throws an exception on bad input, I don't get a surface
object back to query though, leaving me trying to catch exceptions,
analyze them, etc.

>> - 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').
> 
> Good point. I guess there should be a get_error_code() method. A patch
> would be welcome.

I'll see what I can do - No promises though (I'm already involved
with several OpenSource projects, and develop full time all day...)
Ian