Geometry Boost List: [ggl] Definition of exception types

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

Hi Bruno,

Herewith a short top-posted answer, performance is indeed a good reason 
to offer an alternative. By the way, I later thought that this
> void some_function(..., error_type& e = throws)
will probably not compile because a non-const reference parameter cannot 
be a default parameter (I think, didn't try). However this can be solved 
by overloads but it will give extra code.

Regards, Barend

Bruno Lalande wrote:
> Hi,
>
>   
>> 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?
>
> 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.
>
>   
>> It surprises me that this is really the way Boost.System and C++0x will
>> handle this. Because what is the difference from calling it with a code, and
>> try { some_function(...) } catch {std::exception& e)?
>>     
>
> I'm not an expert but if I remember well, a try/catch is not free at
> all. Testing a return code is much faster. But having return codes
> checked everywhere makes the code unreadable and error-prone
> (precisely...). That's why it's adviced (see Herb Sutter's article
> about that) to return an error code if the error can be handled close
> to the calling site (ideally, in the caller itself) and throw an
> exception otherwise.
>
> The problem is that it can be difficult to know whether the error
> handling site is close to the calling site or not. It greatly depends
> of the user's code. That's why the proposed solution sounds pretty
> good.
>
>   
>> Thinking futher about
>> this, if we do it like this, can we implement it like follows?
>>
>> void some_function(..., error_type& e = throws)
>> {
>>   try { some_function(...); } catch(std::exception const& ex) {
>> e.error_message = ex.what(); }
>> }
>>     
>
> Certainly not IMO, for performance reasons.
>
>   
>> Also important: what will the return value be (in case of non-void) and the
>> output parameters?
>>
>> [...]
>>
>> 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...
>
> Regards
> Bruno
> _______________________________________________
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090617/31be7554/attachment-0001.html