Geometry Boost List: [ggl] Definition of exception types

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

Hi,

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

I've included this test in the comparison programs and I cannot find any 
difference. If it is for speed alone, it seems that any other measure is 
more effective than this one...

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

I'm not convinced that we should *at this moment* switch to error codes 
instead of or in addition to exceptions. I propose to leave this for a 
while and continue with preview 5 without, it has too much influence on 
both interface and implementation to work this out now.

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090622/0317bf0a/attachment.html