Logging just arised exception

Question

Is this idiomatic/pythonic to do like this or is there a better way? I want all the errors to get in log for in case I don't have access to the console output. Also I want to abort this code path in case the problem arises.

    try:
      with open(self._file_path, "wb") as out_f:
           out_f.write(...)
           ...
    except OSError as e:
        log("Saving %s failed: %s" % (self._file_path, str(e)))
        raise

EDIT: this question is about handling exceptions in a correct place/with correct idiom. It is not about logging class.

Possible duplicate of [Using the logging python class to write to a file?](https://stackoverflow.com/questions/6386698/using-the-logging-python-class-to-write-to-a-file) — Paulo Almeida, Jul 18 '17 at 15:00
I don't really get the downvotes nor closing votes here. As far as I'm concerned it's a pretty sensible question, and definitly not "opinion based". — bruno desthuilliers, Jul 18 '17 at 15:35
@VladimirLenin Sorry, I had misunderstood the question. The `try:` in the beginning helps, I thought the file opening was unrelated to the `except` :) — Paulo Almeida, Jul 18 '17 at 16:37
@VladimirLenin partly unrelated but for your example snippet you want to catch IOErrors as well (`except (OSError, IOError) as e:`) — bruno desthuilliers, Jul 19 '17 at 10:37

bruno desthuilliers · Accepted Answer · 2017-10-03T11:50:47.383

A proven, working scheme is to have a generic except clause at the top level of your application code to make sure any unhandled error will be logged (and re-raised fo course) - and it also gives you an opportunity to try and do some cleanup before crashing)

Once you have this, adding specific "log and re-reraise" exception handlers in your code makes sense if and when you want to capture more contextual informations in your log message, as in your snippet example. This means the exception might end up logged twice but this is hardly and issue .

If you really want to be pythonic (or if you value your error logs), use the stdlib's logging module and it's logger.exception() method that will automagically add the full traceback to the log.

Some (other) benefits of the logging module are the ability to decouple the logging configuration (which should be handled by the app itself, and can be quite fine-grained) from the logging calls (which most often happen at library code level), the compatibility with well-written libs (which already use logging so you just have to configure your loggers to get infos from 3rd-part libs - and this can really save your ass), and the ability to use different logging mechanisms (to stderr, to file, to syslog, via email alerts, whatever, and you're not restricted to a single handler) according to the log source and severity and the deployment environment.

Update:

What would you say about re-raising the same exception (as in example) or re-raising custom exception (MyLibException) instead of original one?

This is a common pattern indeed, but beware of overdoing it - you only want to do this for exceptions that are actually expected and where you really know the cause. Some exception classes can have different causes - cf OSError, 'IOErrorandRuntimeError- so never assume anything about what really caused the exception, either check it with a decently robust condition (for example the.errnofield forIOError`) or let the exception propagate. I once wasted a couple hours trying to understand why some lib complained about a malformed input file when the real reason was a permission issue (which I found out tracing the library code...).

Another possible issue with this pattern is that (in Python2 at least) you will loose the original exception and traceback, so better to log them appropriately before raising your own exception. IIRC Python3 has some mechanism to handle this situation in a cleaner way that let you preserve some of the original exception infos.

Thanks for detailed reply. What would you say about re-raising the same exception (as in example) or re-raising custom exception (MyLibException) instead of original one? The second option appeals to me allowing to narrow down the possible exceptions set, knowingly generated by my library. It also allows to distinguish errors which are known to the library. — noname7619, Oct 03 '17 at 11:28

Logging just arised exception

1 Answers1