[geos-devel] Exception policy

[strk]

About the SIGABORT, I've found the problem.
It's my fault.
Trying to make the code strict I've added some throw() specifications
and I missed to include some of the possible trhown exceptions,
in particular AssertionFailedExceptions.

I've now modified some of the code to specify a GEOSException *,
from which AssertionFailedExecption derives.

I did not known that, but I've learned that once you add a throw
specificaion you cannot catch exceptions not specified in the
list, but you're bound to receive a terminate()->abort() call.

Now. Since it is in theory possible that exceptions other then
GEOSException are thrown (out of memory for example), how should
GEOS act, being it a library ?
Should we completely omit throw specifications ?
Is the default abort() acceptable in this case ?
Should we add 'exception' to the specification list ?

Comments welcome.

--strk;



On Mon, Apr 26, 2004 at 10:09:20PM -0400, Carl Anderson wrote:
> On 04/26/2004 12:20:42 PM, strk wrote:
> > On Mon, Apr 26, 2004 at 09:11:04AM -0700, Martin Davis wrote:
> ...
> > > no need to pass it to the toGeometry method.  Really, the  
> > toGeometry
> > > method is only there to support converting Envelopes to a Geometry  
> > -
> > > it's not intended for outside use.  Probably should be
> > package-private
> > > in JTS.
> > >
> > > Make sense?
> > 
> > Sure, so the bug is in the comment alone :)
> > If that function is not part of the API, what code was trying to use
> > it Carl ?
> > 
> > --strk;
> 
> in PostGIS-0.8.1
> postgis_geos_wrapper.cpp:
>     g = geomFactory->toGeometry(envelope,geomFactory-
> >getPrecisionModel(), SRID);
> 
> matches a function in GEOS-1.0 but does not match anything in GEOS-CVS
> 
> Pls remember that my original email was addressing two seperate issues
>    (1) - the API creep
>    (2) - the stability of the geos library due to Asserts /
>         Exceptions / SegFaults.  Especially in the context of the
>         C program Postgres
> 
> the latter involve bugs, the former with tagging and whether fixes to  
> 1.0.0 or CVS would be appropriate.
> 
> C.
> 
> --
> Carl Anderson
> GIS Manager Fulton County Georgia
> carl.anderson at vadose.org
> carl.anderson at co.fulton.ga.us
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel