[geos-devel] Exception Issues

[Norman Vine]

Martin Davis writes:
> 
> > There is some confusion as to how to handle
> > C++ exceptions, which are NOT the same thing as JAVA exceptions
> 
> <rant>
> Norman, you could well be right here, if you are talking about 
> the precise semantics of the C++ VS Java execution model.  The 
> Java execution semantics are pretty well defined (witness the 
> high level of portability of code between different JVMs).  C++ 
> semantics are MUCH less well defined (witness the current 
> problems with exceptions to do with the compiler?  the linker?  
> the dynamic loader?  - all these tools vary greatly between 
> different implementations, in undocumented and unpredictable ways)   
> </rant>

C++ semantics are *very* well defined, it is just that they may vary a bit
between implementations :-)

However I believe this has little bearing on our problem, which AFAICT, 
stems from the fact that once you declare a try block in C++ *all* the 
exception handlers that have been declared come into play, this includes 
the *standard* exceptions !

Our problem is that we were AFAICT never trying to catch any 
exceptions other then those defined by GEOS hence when a
standard exception was thrown it was never caught and therefore
the underlying C++ standard terminate() handler was called when
a standard exception was raised.

> That said, it's my belief that both C++ and Java exceptions are 
> designed to do pretty much the same thing - allow transfer of 
> control and error information up through the execution stack with 
> minimal impact on code which does not handle the error. 

YES

> In C++ 
> this is trickier than in Java, since you need to manually clean 
> up memory resources as you unwind the stack.  (The <autoptr> 
> thingie in STL is supposed to help with this).  But I think we 
> can accomplish this with some reasonable diligence.

IMO We should consider the <autoptr> thingie or its equivalant
in that once adopted it's use is efficient, transparent and prevents
unhandled exceptions in that an objects destructor will deallocate
memory as required  :-)
 
> > That said now that we have all of the PostGIS GEOS interaction
> > in a C++ not a C library we should be able to handle any "standard"
> > exception thrown by the GEOS code by including it within an 
> > appropriate  try block
> 
> As I understand it, the problem we have is such that we can't 
> simply fix it by wrapping each GEOS function in a try block.  (In 
> fact, I think this was proposed and tried when we first 
> encountered the problem). The problem is deeper than that - it 
> goes back to what I said earlier about unexpected and widely 
> varying semantics of the C++ execution model.  

I don't think so esp since the *only* C++ code we are considering
here is *all* contained inside GEOS and the PostGIS-GEOS wrapper
which we have *complete* control over.  ie PostgreSQL is only 'C'
and knows *nothing* about C++ exceptions and could care less about
them :-)

> In this case, the 
> compiler or linker being used handle a throw as an abort - which 
> is probably not be considered as adherence to the generally 
> accepted model of C++ execution.

It actually is calling the *default* exception handler which is 
essentially the 'C' abort().  This is only because when unwinding
the stack there is no appropriate handler found for the exception
being called and this is the required 'behavior as defined by the 
'C++ standard'.

In order for me to help much more in debugging this it would
help considerably if there was a common test suite that demonstrates
the problem.

At a minimum this would consist of
1) A common PostGIS data set
2) The PostGIS GEOS enabled SQL query that causes the behaviour
     on this data set

I will try to come up with this but please remember that any of my work 
on GEOS and PostGIS is done in my 'free' time and thus has 'free time' 
priority.

Cheers

Norman