Geometry Boost List: [ggl] Definition of exception types

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

>
>> Yes. The code I presented was there to define the error_type usable as the
>> default argument:
>>
>>    some_function(..., error_type& e = throws);
>>     
>
> OK, wasn't obvious to me. I guess the "error_type" in the line above
> is actually what you call "error_code" in the adaptation code you sent
> after.
>
> This solution sounds definitively good to me. It makes error handling
> in GGL very flexible to the users' needs, and makes us already
> compliant to the upcoming standard.
>
>   

It might indeed be convenient, from user perspective, to influence how 
errors/exceptions are handled. I'm glad we don't have too many places 
were exceptions are raised. But parsing is of course different.

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?

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)?  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(); }
}

What is actually the advantage above a standard exception?

Also important: what will the return value be (in case of non-void) and 
the output parameters?

Example: let's take "centroid", it currently has 4 forms:

inline void centroid(const G& geometry, P& c)

inline void centroid(const G& geometry, P& c, const S& strategy)    

inline P make_centroid(const G& geometry)

inline P make_centroid(const G& geometry, const S& strategy)

For clarity: the point type P can be different than the point type used 
by G. The second two forms require that the point type is specified. The 
strategy is sort of optional (actually like the error_type would be).

If we add the error-parameter there, it will look like this:

inline void centroid(const G& geometry, P& c, error_type& e = throws)

inline void centroid(const G& geometry, P& c, const S& strategy, error_type& e = throws)    

inline P make_centroid(const G& geometry, error_type& e = throws)

inline P make_centroid(const G& geometry, const S& strategy, error_type& e = throws)

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?

So my conclusion is that it is an interesting idea but there are some 
open questions...

Regards, Barend

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/ggl/attachments/20090616/545226bd/attachment-0001.html