Geometry Boost List: [ggl] Definition of exception types

Subject: [ggl] Definition of exception types
From: Hartmut Kaiser (hartmut.kaiser)
Date: 2009-06-17 10:03:58

> > However, if there is no exception, the code continues. So the code
> will
> > internally be more complicated, having to return everywhere. Besides
> that,
> > if there is an exception outside of our code (e.g. boost lexical
> cast), we
> > have to catch that exception and then either rethrow it or set the
> > error_type parameter and return. Right?
> 
> Hmm not sure you're right here. The goal is not to replace the already
> existing error handling method of underlying libraries, but to define
> one for ours. The fact that the user specifies an error_type doesn't
> mean he doesn't want any exception at all (if there's a lack of memory
> I guess he doesn't wait anything else than a bad_alloc thrown). He
> just says that in case of functional error in the logic of the GGL
> function called, he doesn't want an exception. Hartmut, am I right?

That's a tough question. Boost filesystem uses this error handling technique
at a level where no exceptions are to be handled (everything is barely above
the OS). So it's straightforward there. But I think the approach you're
suggesting is a possible one, as it still avoids cluttering the user code
with lots of small try/catch handlers. Heavy duty exceptions as bad_alloc
are normally handled in one or only a couple of place in an application (if
at all :-P). In the end it boils down to be a problem of proper
documentation.

> Note: if an underlying library already uses the standard error
> handling policy we're studying, all you have to do is passing it the
> same error_type and it we automatically behave the same way, if I
> understand correctly.

Might work. Yes. All error_code types are supposed to be derived from
boost::system::error_code, so that's fine.

> > Suppose the input is a polygon an outer ring without any points. We
> do not
> > have any clue about a meaningful centroid, so we raise an exception
> (it is
> > currently done there but have to be cleaned up).
> > What do we return for P in case of an error?
> 
> This in indeed an open question...

Two solutions are possible:

a) those functions will have to throw in any case
b) return a default constructed value of the return type The user needs to
check for an error condition anyways, so no harm done:

    error_code e;
    T t = some_function(..., e);
    if (!e) {
        // handle error, ignoring t
    }

I like b) more, but that's a matter of taste.
Regards Hartmut