[postgis-users] Topological Exceptions

[Martin Davis]

So the question is, does JDBC throw an exception if a query fails with 
an PG error message? 

I'm not sure - my guess is No.  Maybe someone else can confirm this?

In any case, wouldn't this have the same undesired behaviour as the 
original query error (e.g. the query fails before completing, and 
there's not ability to determine which geometries caused the problem) ?

Chris Hermansen wrote:
> I can be so tiresome sometimes!
>
> What I meant to ask was, when bad geometry is encountered and some
> predicates are tempted to give up, what happens in the JDBC context - is
> an exception thrown.  Clearly if you move over to the returning nulls
> then a Java null is the reasonable behaviour.
>
> Sorry to be so unclear!
>
> Martin Davis wrote:
>   
>> 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