Geometry Boost List: [ggl] Definition of exception types

Subject: [ggl] Definition of exception types
From: Hartmut Kaiser (hartmut.kaiser)
Date: 2009-06-17 09:14:59

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

It compiles as long as 'throws' is non-const as well. And this might get
tricky as GGL is a header only library. But I think I know how to solve
this.

Regards Hartmut

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