[postgis-users] Topological Exceptions

[Martin Davis]

I would expect that JDBC would simply return a standard SQL null value. 
  I'm not sure whether JDBC returns an specific object representing 
null, or simply a Java null - I suspect the latter.

Chris Hermansen wrote:
> Martin, I like the direction you're headed in here because it seems it
> can be done with the technology as-is.
>
> Does anybody know what happens if one encounters this while processing
> through e.g. JDBC?  Would one expect an exception of some sort to be thrown?
>
> Martin Davis wrote:
>   
>> Sounds good to me.
>> If you wanted to see which geoms caused the problem, couldn't you just
>> run another query looking only for ones which returned NULL from the
>> operation, and then check the log?
>>
>> The log msg could also give the first couple of points of the
>> offending geoms - that would narrow it down pretty good.
>>
>> Does ST_Contains (and the other predicates) ever result in
>> TopologyExceptions?  They are generally pretty darn robust, to my
>> knowledge.  It's the overlay ops which are the real bad boys.
>>
>> Paul Ramsey wrote:
>>     
>>> On 3/12/08, Martin Davis <mbdavis at refractions.net> wrote:
>>>
>>>  
>>>       
>>>>  Orginally the idea was that it was nice to report the actual nature of
>>>>  the exception, since it contains an indication of where the error
>>>>  occurred.   It would be nice to be able to continue to have access to
>>>>  this information.  One way to do this would be to have a parallel
>>>> set of
>>>>  functions which would abort as they do now.  Or is there some other
>>>> way
>>>>  to report this info - to a log somewhere perhaps?
>>>>     
>>>>         
>>> I prefer using something like NULL to trying to create a new geometry
>>> type to encompass the error... particularly if the error conditions
>>> aren't that interesting to people.  We can get into the log easily
>>> enough by using a WARNING log level, the only question then is how to
>>> identify which geometries caused the failure.  One way might be to
>>> hash the geometries, so that if people want to find their bad
>>> geometries from the log they can just select for the hash value.
>>>
>>> This means that the return values of
>>>
>>> ST_Contains(geom,geom) => true, false or null
>>>
>>> and
>>>
>>> ST_Intersection(geom,geom) => geometry or null
>>>
>>> I just checked, and null seems to be interpreted as false in a WHERE
>>> clause, so adding this behavior probably wouldn't wreck too many
>>> joins.
>>>
>>> Paul
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>>
>>>   
>>>       
>
>
>   

-- 
Martin Davis
Senior Technical Architect
Refractions Research, Inc.
(250) 383-3022