Geometry Boost List: [ggl] Definition of exception types

Subject: [ggl] Definition of exception types
From: Mateusz Loskot (mateusz)
Date: 2009-06-14 12:38:07

Hartmut Kaiser wrote:
>> I'd like to collect some thoughts and guidelines about exception types
>> defined in GGL.
>>
>> Do we stick to Boost guidelines [1] ?
>>
>> Should we have abstract ggl::exception defined as std::exception
>> subclass and derive all other exceptions from it?
>>
>> I'd suggest to prefer to std:: naming with _error postfix, for instance
>> ggl::wkb::value_error, than what I have now:
>> ggl::value_wkb_exception
>> and others.
>>
>> Among others, there seems to be two structures popular:
>>
>> 1. All GGL exceptions live directly in ggl:: and are defined in single
>> file, for instance:
>>
>> ggl::wkb_value_error
>> ggl::wkb_read_error
>>
>> 2. Exceptions are categorized using namespace
>>
>> ggl::wkb::value_error
>> ggl::wkb::read_error
>> ggl::wkb::write_error
>> ggl::wkt::write_error
>> ...
>> ggl::algorithm::intersection_error
>> ...
>>
>> Which to prefer?
> 
> A bit off-topic perhaps, but what I prefer when using an API is to have the
> choice between throwing and non-throwing behavior of a particular function.

I agree it's good to have the convenience of choice here.

> I think the filesystem library uses a nice way to implement both behaviors
> using the same function:
> 
>     error const throw_error = error();   // global sentinel
> 
>     void some_function(error& e = throw_error)
>     {
>         // error handling:
>         if (&e == &throw_error) {
>             // throw error
>         }
>         else {
>             // set e to the error and return
>         }
>     }
> 
> Allowing to use the function either as:
> 
>    some_function();    // throws on error
> 
> or
> 
>    error e;
>    some_function(e);   // doesn't throw, but sets 'e' on error

Generally, I like this idea. However, I'm having problems trying to
imagine how to implement this kind of mechanism in GGL without
making the API too messed.

> I don't think it's a good idea to use the exception types as the error type
> above.

Do you mean the error type in filesystem example or type per error
category I listed in my first post?

> In fact the file system library uses the system::error type for this
> purpose. I'm not sure, how to implement that in GGL.

I'm not sure either, but the idea is interesting.

> But I thought to throw it on the table here, at least for the sake of
> discussion.

IMHO, it's very relevant here.
Consistent convention on errors handling is one of the hardest to define
but one of most appreciated feature of a library.

Cheers
-- 
Mateusz Loskot, http://mateusz.loskot.net
Charter Member of OSGeo, http://osgeo.org