Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#3632 closed defect (fixed)

UseExceptions() supresses all debug output and warnings.

Reported by: warmerdam Owned by: hobu
Priority: normal Milestone: 1.8.0
Component: PythonBindings Version: unspecified
Severity: normal Keywords:
Cc:

Description

In Python invoking UseExceptions?() installs a quiet error handler that causes all debug output and warnings to be discarded. I think this is inappropriate.

Change History (4)

comment:1 Changed 10 years ago by warmerdam

Resolution: fixed
Status: newclosed

I have committed a change in trunk (r19845) which avoids discarding warnings and debug messages. It also attempts to use the previously installed error handler rather than assuming that the default error handler was necessarily previously installed.

Howard, do you see any problems likely to come from this change?

In theory it could go back into 1.7 but I'd rather let it play out for a while before doing such a thing.

comment:2 Changed 10 years ago by hobu

Does this mean debug and info messages now continue on to stdout as before in the DontUseExceptions? case? A significant reason for the quiet error handler is to prevent noise from going to stdout in situations where it's not appropriate like server apps and the like. I wouldn't want UseExceptions?'s semantics in this effect to revert back to the previous DontUseExceptions? behavior.

How about UseExceptions? and then UseNoisyDebug? and break these into two different things?

I do not support this going back to 1.7 if it is not split into an additional optional call.

comment:3 Changed 9 years ago by warmerdam

Howard,

debug and warning messages are now processed normally which by default means they are sent to stderr. Note that debug messages are not enabled by default, but if the user has explicitly enabled them this ensures that they still go somewhere.

I think that whether or not CE_Failure errors are intercepted and turned into exceptions should not have any any impact on debug messages. I can see warnings as a grey area.

Note that in server applications where folks don't want anything going to stderr it is best to call gdal.PushErrorHandler?( 'CPLQuietErrorHandler' ) which will explicitly quiet warnings and errors. This is appropriate whether using exceptions or not.

For this reason I do not believe it is necessary to have a UseNoisyExceptions? method.

I am happy enough not to back port this into 1.7 as it might cause surprising differences in what should just be a bug fix release.

comment:4 Changed 9 years ago by hobu

Our plan was to have UseExceptions? be on by default for 1.8, so we should actually discus a bit what we intend that to be :) IMO (and Kevin's too at the time), turning it on was to only throw exceptions for errors, and ignore all else.

Here's my principles of exception handling in the Python bindings in 1.8+:

  • Only CE_Failure and CE_Fatal (if possible) cause real exceptions to be thrown
  • The user is afforded some convenience to turn on or off the flow of both warnings and debug output.
  • My opinion is that the default for warnings is off unless CPL_DEBUG=ON is set, and in that case both warnings and debug would be emitted.
  • We (I) should put some effort into integrating into Python's generic logging facilities and provide handlers for the various logging types that appear to easily map to Python's logging primitives http://docs.python.org/library/logging.html If that were done, a user could connect to the GDAL Python logging handler and filter information that they wished.
Note: See TracTickets for help on using tickets.