[geos-devel] Exceptions

[Martin Davis]

Yes, absolutely.  The whole idea behind structured exception handling is so that higher layers of client code can catch some or all of them and handle them intelligently.  To do this, exceptions need to be typed, and they often need to carry extra information about the nature of the error.  

If every exception thrown is a string, the only handling strategy possible is to abort printing out the string.

It's easy to degrade exceptions to strings, but very hard to make them back into typed exceptions.  If typed exceptions are causing a problem, the answer is to catch them all in the "C PostgresQL wrapper" and convert them to strings.

Martin Davis, Senior Technical Architect
Vivid Solutions Inc.
Suite #1A-2328 Government Street   Victoria, B.C.   V8T 5G5
Phone: (250) 385 6040    Fax: (250) 385 6046
EMail: mbdavis at vividsolutions.com  Web: www.vividsolutions.com


> -----Original Message-----
> From: Paul Ramsey [mailto:pramsey at refractions.net]
> Sent: Saturday, April 19, 2003 12:23 AM
> To: GEOS List
> Subject: [geos-devel] Exceptions
> 
> 
> The exceptions continue to muck with us. Exceptions thrown in 
> geos have 
> not been catchable, and are taking down the postgres backend with 
> sigabort. I did a grep for "throw" in the source code, and the 
> exceptions are a bit of a mishmash. Most of them are of the form,
> 
>    throw "PointCoordinateList exception: can't retrieve element\n";
> 
> But some are of the form,
> 
>    throw new ParseException(e.toString());
> 
> or
> 
>    throw ParseException("Expected number but encountered ')'")
> 
> So, sometimes we are throwing strings, sometimes we are throwing new 
> exception objects and other times just static things?
> 
> Anyhow, we have had better luck catching the simple throws (the 
> strings). Is there a reason for throwing specially constructed 
> exception objects?
> 
> 
>       Paul Ramsey
>       Refractions Research
>       Email: pramsey at refractions.net
>       Phone: (250) 885-0632
> 
> 
> _______________________________________________
> geos-devel mailing list
> geos-devel at geos.refractions.net
> http://geos.refractions.net/mailman/listinfo/geos-devel
>