Geometry Boost List: [ggl] Definition of exception types

Subject: [ggl] Definition of exception types
From: Hartmut Kaiser (hartmut.kaiser)
Date: 2009-06-14 10:40:59

> 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 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

I don't think it's a good idea to use the exception types as the error type
above. In fact the file system library uses the system::error type for this
purpose. I'm not sure, how to implement that in GGL.

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

Regards Hartmut