Exception-Safety of `TrinoUserError::error_location`

[stephen-zhao]

I wrote an error handler which catches a TrinoUserError e and attempts to write out all the TrinoQueryError subclass properties. Unfortunately, when attempting to print out e.error_location, it will cause another throw because it doesn't seem to exist for some shapes of TrinoUserError. Below is an example:

TrinoUserError(type=USER_ERROR, name=PERMISSION_DENIED, message="Access Denied: Cannot select from columns [cccccc] in table or view tttttt", query_id=xxxxxx)

The exception I get is the following:

Traceback (most recent call last):
  <REDACTED>
  File "<REDACTED>", line <REDACTED>, in <REDACTED>
    f", location = {e.error_location}"
                    ^^^^^^^^^^^^^^^^
  File "<REDACTED>/trino/exceptions.py", line 109, in error_location
    location = self._error["errorLocation"]
               ~~~~~~~~~~~^^^^^^^^^^^^^^^^^
KeyError: 'errorLocation'

Is it possible to make this key access throw-safe? e.g. by using "get" with a fallback value when invalid (automatic way of handling it), or exposing some method to check if error_location is available first (put it in the hands of consuming application).

trino-python-client/trino/exceptions.py

Lines 111 to 113 in 1e95bbf

	def error_location(self) -> Tuple[int, int]:
	location = self._error["errorLocation"]
	return (location["lineNumber"], location["columnNumber"])

All of the other ones return Optional[T] using .get as the underlying access method.

[stephen-zhao]

The workaround I will put into place for now is a nested try/catch:

try:
    # do query
except TrinoUserError as e:
    error_location: tuple[int, int] | None
    try:
        error_location = e.error_location
    except KeyError:
        error_location = None
    # do things with error_location...

[hashhar]

@stephen-zhao I think what you're proposing (get with default) makes sense. Will you be open to sending a PR?

[stephen-zhao]

Yes, although this would be a backwards incompatible change to the interface. Will that be ok?

EDIT: Not strictly true from an untyped perspective. But if someone has explicitly typed the return value, it would be "breaking"

[hashhar]

I think it's fine.