On Apr 22, 2005, at 16:51, holger krekel wrote:
> Moreover, i think that there are more than the "transactional"
> use cases mentioned in the PEP. For example, a handler
> may want to log exceptions to some tracing utility
> or it may want to swallow certain exceptions when
> its block does IO operations that are ok to fail.
I entirely agree! In fact, I was discussing this very issue recently
with colleagues at Google, most of them well acquainted with Python but
not all of them Python enthusiasts, and I was surprised to see
unanimity on how PEP 310 *with* __except__ would be a huge step up in
usefulness wrt the simple __enter__/__exit__ model, which is roughly
equivalent in power to the C++ approach (destructors of auto variables)
whose absence from Python and Java some people were bemoaning (which is
how the whole discussion got started...).
The use cases appear to be aleph-0 or more...;-). Essentially, think
of it of encapsulating into reusable forms many common patterns of
try/except use, much like iterators/generators can encapsulate looping
and recursive constructs, and a new vista of uses open up...
Imagine that in two or three places in your code you see something
like...
try:
...different blocks here...
except FooError, foo:
# some FooError cases need whizbang resetting before they propagate
if foo.wobble > FOOBAR_RESET_THRESHOLD:
whizbang.reset_all()
raise
With PEP 310 and __except__, this would become:
with foohandler:
...whatever block..
in each and every otherwise-duplicated-logic case... now THAT is
progress!!!
IOW, +1 ... !
Alex
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