[cairo] cairomm exception handling questions
britten at caris.com
Mon Aug 11 11:45:35 PDT 2008
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:
> this is the (indirectly) recommended exception for this cairo error:
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
>> 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
> 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:
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
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...)
More information about the cairo