Boost logo

Geometry :

Subject: [ggl] Definition of exception types
From: Barend Gehrels (Barend.Gehrels)
Date: 2009-06-17 11:08:17


Hartmut Kaiser wrote:
>> 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.
OK, clear.

>> 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
OK, everything seems to be solvable and convenient. Let me do some
experiments with it, coming weekend... I'll take the centroid and I'll
come back to it.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...

Geometry list run by mateusz at