try/except/else flexibility... 
Author Message
 try/except/else flexibility...

Just a thought: Given the prevalence of try/except/else in the "don't
look before you leap" way of doing things, could it be useful to make
the statement more flexible? For instance, instead of writing

  try: foo + ''
  except: pass
  else: bar()

(assuming I'm sloppy enough not to specify TypeError on the second
line) one could simply write:

  try: foo + ''
  else: bar()

and if I want something done only if it causes no exceptions, for
instance pop off an element of a list unless it is empty, I could just
do:

  try: somelist.pop()

Is this heresy? I see the harm in not specifying exactly which
exceptions you're expecting, of course -- are there other arguments
against this? (I'm sure that might be argument enough... Oh, well...)

--
Magnus Lie Hetland                                  The Anygui Project
http://www.*-*-*.com/                                   http://www.*-*-*.com/



Tue, 28 Sep 2004 12:30:27 GMT  
 try/except/else flexibility...
        ...

Quote:
>   try: foo + ''
>   else: bar()

> and if I want something done only if it causes no exceptions, for
> instance pop off an element of a list unless it is empty, I could just
> do:

>   try: somelist.pop()

> Is this heresy? I see the harm in not specifying exactly which
> exceptions you're expecting, of course -- are there other arguments
> against this? (I'm sure that might be argument enough... Oh, well...)

It seems to me that forgetting or mis-aligning an except or finally
clause is an error that these language changes would make it harder
to diagnose.  I'm an enthusiast for "easy to ask forgiveness than
permission", but this way you would make it easiest and most
natural to not even ask permission.  I think this would take us
back too close to (say) the typical problem with C -- system calls
or library functions carefully giving out error codes, and bulldozing
application programmers totally ignoring those codes and doing no
error-checking at all.  One advantage of exceptions is that the
default is NOT to ignore -- and the ease to just put everything in
a blind 'try:' might, I fear, claw back most of this advantage,

Alex



Tue, 28 Sep 2004 15:12:09 GMT  
 try/except/else flexibility...


Quote:
> Just a thought: Given the prevalence of try/except/else in the "don't
> look before you leap" way of doing things, could it be useful to make
> the statement more flexible? For instance, instead of writing

>   try: foo + ''
>   except: pass
>   else: bar()

> (assuming I'm sloppy enough not to specify TypeError on the second
> line) one could simply write:

>   try: foo + ''
>   else: bar()

> and if I want something done only if it causes no exceptions, for
> instance pop off an element of a list unless it is empty, I could just
> do:

>   try: somelist.pop()

Just to remember you: ;-)))
Quote:
>>> Explicit is better than implicit.
>>> Special cases aren't special enough to break the rules.

and if you want something more explicit:
Quote:
>>> Errors should never pass silently.
>>> Unless explicitly silenced.

And then you could always use something like that (and let the console
remind you how you like to take risks)
Quote:
>>> def tryAndForget(f, *args, **kw):

...  try:
...   return apply(f, args, kw)
...  except :
...   print('I like to live dangerously')

Quote:
> Is this heresy? I see the harm in not specifying exactly which
> exceptions you're expecting, of course -- are there other arguments
> against this? (I'm sure that might be argument enough... Oh, well...)

More seriously, I think that:
try:
    ...
except:
    pass
means something like 'if there is something wrong that I didn't foresee,
please, please don't tell me' which remind me the joke of the guy falling
from a building and saying during the drop 'until now, it's all right, ...
until now, it's all right, ... until now, it's all right ...' (sorry for my
english, it's implemented as you like: every exception is silently absorbed
;-)

The perspective is completely different if you log evething that you didn't
foresee. A kinda tryAndLog function makes sense in some development phases
IMHO.

Have a nice WE

B.

- Show quoted text -

Quote:

> --
> Magnus Lie Hetland                                  The Anygui Project
> http://hetland.org                                  http://anygui.org



Tue, 28 Sep 2004 18:38:49 GMT  
 try/except/else flexibility...


Quote:
> Just a thought: Given the prevalence of try/except/else in the "don't
> look before you leap" way of doing things, could it be useful to make
> the statement more flexible? For instance, instead of writing

>   try: foo + ''
>   except: pass
>   else: bar()

> (assuming I'm sloppy enough not to specify TypeError on the second
> line) one could simply write:

>   try: foo + ''
>   else: bar()

Hmm, trading explicitness for brevity and flexibility.  How about
meeting you halfway:

ignore TypeError:  foo + ''
else:  bar()

Quote:

> and if I want something done only if it causes no exceptions, for
> instance pop off an element of a list unless it is empty, I could just
> do:

>   try: somelist.pop()

ignore IndexError:  somelist.pop()

Raymond Hettinger



Wed, 29 Sep 2004 11:58:21 GMT  
 try/except/else flexibility...

Quote:

> Just a thought: Given the prevalence of try/except/else in the "don't
> look before you leap" way of doing things, could it be useful to make
> the statement more flexible? For instance, instead of writing

>   try: foo + ''
>   except: pass
>   else: bar()

> (assuming I'm sloppy enough not to specify TypeError on the second
> line) one could simply write:

>   try: foo + ''
>   else: bar()

> and if I want something done only if it causes no exceptions, for
> instance pop off an element of a list unless it is empty, I could just
> do:

>   try: somelist.pop()

In the pop() case there is a check that can be done before anything
needs to be done that might not be easily undone, ie. I suppose that

  try: somelist.pop()

is equivalent to:

  if somelist: somelist.pop()

In the general case:

  try: whatever()

a lot may have been done before an exception is evt. thrown
and I don't think there is a way to undo that in python without
a lot of programmer support in try/finally statements.
Databases have commit/rollback, but this requires expensive logging.

Regards,
Ype

P.S.

Quote:
> Is this heresy?

If you look for a language that supports undoing assignments
try Sartre. Sartre supports unassignment, which might
come in handy. However "Unlike traditional programming languages
(or maybe very much like them), nothing in Sartre is guaranteed
except maybe for the fact that nothing is guaranteed",
so YMWV, ie. your milage will vary:
http://www.catseye.mb.ca/esoteric/sartre/index.html

--
email at xs4all.nl



Thu, 30 Sep 2004 06:07:33 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Try-Except equivalent in CW?

2. try import except want lineno from Exception

3. FIXED. try import except want lineno from Exception

4. try except ImportError failing to catch error!

5. How best to write this try/except block?

6. REPOST: try-except-finally question

7. try-except-finally question

8. retry in try:...except:

9. try/finally/except suggestion

10. Assertion vs. try-except

11. What about try:except:finally

12. try: except: on C

 

 
Powered by phpBB® Forum Software