[Neal Norwitz wrote] > Vinay Sajip wrote: > > > > [Neal Norwitz] > > > You could have the logging methods return an int/bool, > > > 1 if succesfully logged, 0 on failure. Let the caller > > > decide what to do. You could even return a failure > > > object or None. The failure object would contain > > > (or be) the exception/problem. > > This violates the principle that logging should be "set and forget". Having > > the logger fail silently has, in past experience, caused fewer problems than > > having to handle errors from the logging system - yet another headache for > > the developer! > > This is my point. It will almost always be ignored...unless > the caller really needs to know the information. The logger > will fail silently, only an object will be returned > (no exception thrown) and the caller can safely ignore it. You cannot necessarily know if there has been a problem with a logging call by the time the logging call returns. That logging call could be asynchronous. Trent -- Trent Mick TrentM@ActiveState.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4