Geometry Boost List: [ggl] Definition of exception types

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

Hi,

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...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090617/d134e225/attachment.html