[SEDONA-607] Return geometry with ST functions with exceptions

[zhangfengcdt]

Did you read the Contributor Guide?

• Yes, I have read the Contributor Rules and Contributor Development Guide

Is this PR related to a JIRA ticket?

• Yes, the URL of the associated JIRA ticket is https://issues.apache.org/jira/browse/SEDONA-XXX. The PR name follows the format [SEDONA-XXX] my subject.

What changes were proposed in this PR?

This PR make it feasible to return the geometry with the exception when ST functions fail and it will allow users to more quickly root cause exception and failures in their application.

How was this patch tested?

All unit tests and new unit tests on failed st function should throw expected error messages.

Did this PR include necessary documentation updates?

• Yes, I have updated the documentation. [TODO]

[jiayuasu]

@Kontinuation @zhangfengcdt Can we also emit the values of non-spatial fields to provide more hints?

[Kontinuation]

@Kontinuation @zhangfengcdt Can we also emit the values of non-spatial fields to provide more hints?

I don't think it is possible given the current approach to solve this problem.

Another concern is: sometimes the exceptions is not raised by ourselves, but somewhere inside JTS. This mostly happens in overlay functions (intersection, union, etc) and some topology-preserving transformation functions. We have to catch exceptions thrown by JTS and convert them to our own IllegalGeometryException exception, this is very tedious and certainly not what we want to do.

[zhangfengcdt]

@Kontinuation @zhangfengcdt Can we also emit the values of non-spatial fields to provide more hints?

I don't think it is possible given the current approach to solve this problem.

Another concern is: sometimes the exceptions is not raised by ourselves, but somewhere inside JTS. This mostly happens in overlay functions (intersection, union, etc) and some topology-preserving transformation functions. We have to catch exceptions thrown by JTS and convert them to our own IllegalGeometryException exception, this is very tedious and certainly not what we want to do.

Thanks, @Kontinuation @jiayuasu for the suggestions. I have refactor the code to add the input row string to the exceptions. Also, in case input is null (e.g., rows are created in test using SQL literals), I add the literals to the exception. This will help with the debug cases as well.