Geometry Boost List: [ggl] Definition of exception types

Subject: [ggl] Definition of exception types
From: Bruno Lalande (bruno.lalande)
Date: 2009-06-17 04:18:32

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