[geos-devel] Re: [postgis-users] GEOS / Predicates Update

[Ferdinando Villa]

> >   - Re-write some chunks of GEOS to not throw exceptions. This is bad 
> > for two reasons.  It is a large amount of work, and it also is bad 
> > design.  The exceptions are there for a reason, and replacing them with 
> > large chains of null handling will be unpleasant.  There are some 
> > "exception emulation" libraries for C which could make the process less 
> > unpleasant, but it will still not be nice at all.
> 
> I'm voting for this option because I think the compiler-and-library 
> version problem will solve itself over time (click your feet and say 
> "there's no place like home").
> 
> There are remarkably few THROWs in GEOS - only about 63.  There are
> only about 20 CATCHes.

...or maybe something like

template <typename return_value_of_func>
bool handle_error(GeosException* exc, return_value_of_func error_return)
	throw (GeosException*)
{
   if (geos::use_exceptions)
     throw exc;
   else
     delete exc;
   return error_return;
}

and instead of 
   throw new GeosException(...);
we write
   return handle_geos_error(new GeosException(...),
                            whatever_we_should_return);

may be a bit of a pain to use the return value and it's ugly, but it
would control it all with a single global var and leave the exceptions
as a default option.


> The simpliest way to do the conversion would be to have the functions
> return, say, NULL if an error occurred.  The calling function would have 
> to check to see if the result is NULL - if it is it could propogate the 
> error up.
> For functions that have NULL as a valid result, you could return a 
> simple object like this (excuse my java pseudo-code):
> {
> 	boolean errorOccurred;
> 	Object result;
> }
> The calling function would check to see if result.errorOccurred is true. 
>    This could be auto-matically handled using macros.  There are already 
> existing exceptions-for-C open source projects that do something like this.
> 
> There are two problems with this:
> 1. I'm not sure how the code is layed out - there could be a large 
> number of functions to check and modify.  It could also get ugly.
> 2. Libraries and things like templates may throw-errors-behind your back.
> 
> 
> >   - Re-write GEOS entirely, and again, in C. This at least would be a 
> > clean implementation of the algorithms, but it is even more work, and 
> > would constitute yet another port of JTS which would have to be kept 
> > synchronous with the JTS R&D over time.
> 
> I dont think this would be wise idea - its way too much work for too 
> little gain.  Any C implementation would be uglier than C++ without
> exceptions.
> 
> 
> dave
> 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
-- 
ferdinando villa, ph.d.                    associate professor
gund institute for ecological economics, university of vermont
590 main street, burlington, vt 05405    phone: (802) 656-2972