[postgis-users] Dealing with GEOS exceptions

[David Blasby]

Just before I left for holidays (I returned today), I tried to create a 
wrapper around the GEOS functions so that proper exception handling 
would occur.

Unfortunately, it failed.  The code is in CVS (i think) - 
headers/GeometryCAPI.h and util/GeometryCAPI.cpp. I've include some of 
it below so you could see what its doing.  

Unfortunately, this wrappers did not work.  It works in situations like 
this where there is no stack-unrolling-exception handling:

// this function always returns 0
int f()
{
    try
    {
            throw "an exception occurred";
            // never get here
    }
    catch (...)
    {
         return 0;
    }
    return 1;  // never get here either
}

If you try something like this, where there is a stack-unrolling, it 
doesnt work:

int g()
{
    throw "an exception occured";
// never get here
}

// this function will cause a SIGABORT and terminate.
int f()
{
    try
    {
            g();  // g() throws an exception
            // never get here
    }
    catch (...)
    {
         return 0;
    }
    return 1; // never get here
}

I'm out of simple solutions now.  The only thing I can think of trying 
is using the most
up-to-date gcc/g++ and libc/libc++.  Unfortunately, this isnt a very 
nice option (I'm not
even sure if it would work) because it would force everyone to use these 
programs
and libraries - that could be difficult.

Another solution would be to link postgresql with libc++ instead of
libc.  Unfortunately, this would force people to have a non-standard 
postgresql installation,
something I dont think is an option.

If anyone has *ANY* suggestions or thoughts, please let me know.


-------------------------------------------------------------------------------------

// This is just a simple wrapper for basic geometry functions.  See the
// Geometry type documentation for exact definition for these functions.
//
//
// Because some C programs might have trouble calling C++ (most notably
// postgresql, PERL, PYTHON, JAVA, etc...) when there is triple indirect
// access  (postgresql -> libpostgis -> libgeos).
// A more technical discussion of this bug is at 
http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=37
933
//  Basically, if libc is loaded before libc++ exception handling might 
be comprimised.
// 
// This class solves this problem.  It basically wraps try..catch blocks 
around the obvious
// calls to GEOS functions.
//
// For functions that return a boolean (ie. g->isValid() or 
g1->disjoint(g2)), these functions
// return:
//     0  -- FALSE
//     1  -- TRUE
//     2  -- ERROR OCCURRED  * usually due to invalid geometry or 
robustness failure
//
//
//  For functions that return objects (ie. g->asText(), g1->relate(g2)), 
these functions
//  return either the appropriate object or NULL if an error occurred.
//
//
// Usage:
//  if you want to do
//     g1->relate(g2);
//
//  then you do:
//              GeometryCAPI *capi = new GeometryCAPI();
//              char result        =  capi->relate(g1,g2);
//              if (result ==2)
//              {
//                      //handle error
//              }
//
//
//  GeometryCAPI also handles geometry construction.  When you create a 
GeometryCAPI,
//  you also make a new GeometryFactory (see GeometryCAPI constructors 
vis-a-vis GeometryFactory).

...

        Geometry *GeometryCAPI::createPoint(Coordinate *c)
        {
                try{
                        Geometry *result =factory->createPoint(*c);
                        return result;
                }
                catch (...)
                {
                        return NULL;
                }
        }
....
char GeometryCAPI::touches(Geometry *g1, Geometry*g2)
{
        try {
                bool result;
                result =  g1->touches(g2);
                if (result)
                        return 1;
                else
                        return 0;
        }
        catch (...)
        {
                return 2;
        }
}