Re: [cairo] Re: cairo c++ bindings

[Rui Pires <themidgard gmail com>]

The errors aren't really being ignored. Cairo just guarantees it will
not crash if you use a resource that is in an error state. I think this
is much like being able to delete a NULL pointer without having nasty
side effects.

But I still think using policies would give the user of the wrapper more freedom.
A error-reacting policy wouldn't need to restrict itself to throw an
error or not. It could be custom defined by the user of the wrapper.
We could write different policies that could:
* Very easily define set_ignore_errors(bool) as a mix-in method.
* Completely ignore the errors, so that they would only be checked "manually" at convenient times
* Throw exceptions when an error was detected

This has the advantage of passing those pesky choices to the wrapper's end-user.
If I don't like to have any kind of run-time overhead in my wrapper, I
would simply select the error-ignoring policy. If I want a choice at
run-time I would use the policy with the mix-in, etc ...
If someday someone decided they needed something different, they could just write a new policy and that would be it.

I think this gives the user more flexibility and would make Cairomm a very good wrapper.

On 11/24/05, Murray Cumming <murrayc murrayc com> wrote:

> On 11/24/05, Carl Worth <cworth cworth org> wrote:
>>
>> No. C coders are not meant to call _get_status repeatedly. What
>> happens is that if _get_status would return an error status then
>> basically all of that object's functions become NOOPs. That is, it is
>> still safe to call functions on that object and defer the _get_status
>> error checking until a convenient time.
>>
>> If binding to a language that supports exceptions it probably does
>> make sense to call _get_status after each call and throw exceptions.
>>
>> -Carl
>>
>>
> I don't know if anyone else agrees with me, but I think the idea of having
> the wrapper be configurable with a policy to handle the errors is highly
> attractive.
> The alternative would be to have a bool checkForErrors and check if before
> checking and handling errors. This would imply run-time overhead, while
> using the policies would not.

An if(somebool) will not add a significatn amount of run-time overhead.
I'd be happy to add a Cairo::set_ignore_errors(bool) function.

This use of exceptions does seem slightly unusual. If an error can be
ignored, then it does not seem to be an exceptional error.

Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com