Should we revisit GDAL UseExceptions() ?

[dcdenu4]

From #636
Emily:

also curious if you've ever tried gdal.UseExceptions()?

James:

Yes, although it's been a few years. My recollection was that (at least at the time) gdal.UseException() worked as expected in a limited number of cases, and didn't work as expected in a number of others. Like maybe CPL_ERRORs were exceptions and anything lower priority were warnings? I don't quite remember.

Pushing our own error handler ensures that regardless of what GDAL thinks is exception-worthy, we still have the error message. We could also, of course, do a combination of the two (or raise exceptions of our own here in this function). Who knows ... maybe gdal.UseExceptions() has improved in recent years? In any case, taking a look at gdal.UseExceptions() again feels like out-of-scope for the user's error in this PR, but could be worth exploring again.

Doug:

Yea, I think you nailed it James. Back when we looked at this I believe it only listened to CE_Error or CE_Fatal. This is great but when I come across some errors or maybe they were warnings that should have been errors, the handler was not raising any exception and just hiding the error. That seemed pretty dangerous.

Here's a fun stackexchange I posted from 2012! https://gis.stackexchange.com/questions/30445/is-there-a-way-to-properly-have-gdal-raise-exceptions-in-python

And the ticket I filed that was closed when they moved everything to Github 2 years ago.
https://trac.osgeo.org/gdal/ticket/4800

And what Gdal has in their "gotchas" section currently:
https://gdal.org/api/python_gotchas.html#python-bindings-do-not-raise-exceptions-unless-you-explicitly-call-useexceptions

I'd be curious if they ever built out that setting anymore.

For what it's worth, the example I used in my ticket and SE post is now seemingly handled by gdal.UseExceptions().

>>> gdal.UseExceptions()
>>> array = band.ReadAsArray(xoff=129500, yoff=64700, win_xsize=110, win_ysize=80)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Users\ddenu\Workspace\NatCap\Repositories\venv-space\py38-latest\lib\site-packages\osgeo\gdal.py", line 3834, in ReadAsArray
    return gdalnumeric.BandReadAsArray(self, xoff, yoff,
  File "C:\Users\ddenu\Workspace\NatCap\Repositories\venv-space\py38-latest\lib\site-packages\osgeo\gdal_array.py", line 408, in BandReadAsArray
    _RaiseException()
  File "C:\Users\ddenu\Workspace\NatCap\Repositories\venv-space\py38-latest\lib\site-packages\osgeo\gdal_array.py", line 246, in _RaiseException
    raise RuntimeError(gdal.GetLastErrorMsg())
RuntimeError: realized_sedimentdeposition_latitude_masked.tif, band 1: Access window out of range in RasterIO().  Requested
(129500,64700) of size 110x80 on raster of 129600x64800.

[phargogh]

Well that's an encouraging change to gdal.UseException()!

[emlys]

It seems like this is definitely the way GDAL is going. In recent versions we've started getting FutureWarning: Neither gdal.UseExceptions() nor gdal.DontUseExceptions() has been explicitly called. In GDAL 4.0, exceptions will be enabled by default.. See OSGeo/gdal#7452. Also seems like a huge improvement, we just need to watch out for any error cases that might've slipped through the cracks before. And make sure to properly handle this global state - avoid interference with other packages that might set DontUseExceptions.