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