470,636 Members | 1,462 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 470,636 developers. It's quick & easy.

Method Call in Exception

mwt
In my latest attempt at some Python code, I've been tempted to write
something in the form of:

try:
[...] #doing some internet stuff
except IOError:
alternate_method_that_doesnt_need_internet()

This works when I try it, but I feel vaguely uneasy about putting
method calls in exception blocks. So tell me, Brave Pythoneers, is this
evil sorcery that I will end up regretting, or is it just plain good
ol' Python magic?

Apr 20 '06 #1
8 1115
Em Qua, 2006-04-19 *s 16:54 -0700, mwt escreveu:
This works when I try it, but I feel vaguely uneasy about putting
method calls in exception blocks.
What do you put in exception blocks?!

So tell me, Brave Pythoneers, is this
evil sorcery that I will end up regretting, or is it just plain good
ol' Python magic?


IMHO, the exception block in Python is used a lot in places where you
could use an if-then-else, like your example that could be written as

if internet_available():
[...] #doing some internet stuff
else:
alternate_method_that_doesnt_need_internet()

So yes, I think there's no problem there.

--
Felipe.

Apr 20 '06 #2
mwt

Felipe Almeida Lessa wrote:
Em Qua, 2006-04-19 s 16:54 -0700, mwt escreveu:
This works when I try it, but I feel vaguely uneasy about putting
method calls in exception blocks.
What do you put in exception blocks?!


Usually I just print an error message.

So tell me, Brave Pythoneers, is this
evil sorcery that I will end up regretting, or is it just plain good
ol' Python magic?


IMHO, the exception block in Python is used a lot in places where you
could use an if-then-else, like your example that could be written as

if internet_available():
[...] #doing some internet stuff
else:
alternate_method_that_doesnt_need_internet()

So yes, I think there's no problem there.


Normally I don't like to use exception blocks to do condition-statement
stuff. At least that is how my Java training has programmed me. But in
this case, the condition is whether the internet connection is working
or not, and I don't see any other way to do it. And furthermore, I
don't know if the exceptions-as-logic is a no-no in Python. Hence the
question.

Apr 20 '06 #3
Felipe Almeida Lessa wrote:
Em Qua, 2006-04-19 s 16:54 -0700, mwt escreveu:
This works when I try it, but I feel vaguely uneasy about putting
method calls in exception blocks.


What do you put in exception blocks?!

So tell me, Brave Pythoneers, is this
evil sorcery that I will end up regretting, or is it just plain good
ol' Python magic?


IMHO, the exception block in Python is used a lot in places where you
could use an if-then-else, like your example that could be written as

if internet_available():
[...] #doing some internet stuff
else:
alternate_method_that_doesnt_need_internet()

So yes, I think there's no problem there.


What if the service is overloaded and always times out? For end user
it's basically the same as there is no internet access. I routinely use
the following pattern:

unrecoverable = MemoryError, IOError
try:
do_your_best()
except unrecoverable, e:
util.help_on_error(e)
sys.exit(1)

def do_your_best():
recoverable = IOError, socket.error, SomeOtherError
try:
do_something()
except recoverable, e:
do_something_else()

Apr 20 '06 #4
mwt wrote:
In my latest attempt at some Python code, I've been tempted to write
something in the form of:

try:
[...] #doing some internet stuff
except IOError:
alternate_method_that_doesnt_need_internet()

This works when I try it, but I feel vaguely uneasy about putting
method calls in exception blocks. So tell me, Brave Pythoneers, is this
evil sorcery that I will end up regretting, or is it just plain good
ol' Python magic?


It's ok. In fact a lot of Pythonistas recommend this way over the
alternative, even when you don't have to. For example, a lot of people
recommend this:

try:
name = record.name
except AttributeError:
name = "Freddy"

instead of this:

if hasattr(record,"name"):
name = record.name
else:
name = "Freddy"

I prefer the latter most of the time; however, sometimes (as it appears
in your case) simply trying it and doing something else if it raises an
exception is easier, more straightforward, and more robust than
explicitly testing the condition. One thing to consider is whether
something you don't expect could throw the same exception; might have
to disambiguate them somehow in the except block.

Language-wise, I doubt there are any serious gotchas whem running
regular (as opposed to error handling) code in an except block. So go
right ahead; no need to feel guilty about it.
Carl Banks

Apr 20 '06 #5
Carl Banks wrote:
In fact a lot of Pythonistas recommend this way over the
alternative, even when you don't have to. For example, a lot of people
recommend this:

try:
name = record.name
except AttributeError:
name = "Freddy"

instead of this:

if hasattr(record,"name"):
name = record.name
else:
name = "Freddy"


In this specific case, either of these would be better written as:

name = getattr(record, 'name', 'Freddy')
Apr 20 '06 #6
mwt wrote:
(snip)
This works when I try it, but I feel vaguely uneasy about putting
method calls in exception blocks.
What do you put in exception blocks?!


Whatever fits the specific case...

(snip) Normally I don't like to use exception blocks to do condition-statement
stuff. At least that is how my Java training has programmed me.
http://dirtsimple.org/2004/12/python-is-not-java.html
But in
this case, the condition is whether the internet connection is working
or not, and I don't see any other way to do it.
As Felipe wrote, you could also use a if/else.

And furthermore, I
don't know if the exceptions-as-logic is a no-no in Python.


It's not.

The main guideline here is that a else/if has a constant cost - the test
is always executed -, while a try/except only adds overhead if it's
fired. So - if you leave out purely stylistic or religious
considerations - the 'good' choice depends mostly on the 'cost of the
test'/'cost of the exception' ratio and the 'have connection'/'no
connection' ratio.

--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'o****@xiludom.gro'.split('@')])"
Apr 20 '06 #7

"mwt" <mi*********@gmail.com> wrote in message
news:11*********************@t31g2000cwb.googlegro ups.com...
In my latest attempt at some Python code, I've been tempted to write
something in the form of:

try:
[...] #doing some internet stuff
except IOError:
alternate_method_that_doesnt_need_internet()

I'm only a hack at programming but where I find try: blocks useful is where
I have multiple statements within the try: block, any one or more of which
can produce an exception. I just want to trap a failure and get out of
there. This happens to me for any number of reasons when I drive other apps
through the com interface. (In my job I just write simple apps to make my
job easier, not bomb-proof customer-focused code). So in your case perhaps
you have open connection, find site, get data within the try block, and exit
gracefully if any one fails. How you use it depends on what level of detail
you need.

bwaha

Apr 20 '06 #8
Carl Banks wrote:
mwt wrote:
In my latest attempt at some Python code, I've been tempted to write
something in the form of:

try:
[...] #doing some internet stuff
except IOError:
alternate_method_that_doesnt_need_internet()

This works when I try it, but I feel vaguely uneasy about putting
method calls in exception blocks. So tell me, Brave Pythoneers, is this
evil sorcery that I will end up regretting, or is it just plain good
ol' Python magic?


It's ok. In fact a lot of Pythonistas recommend this way over the
alternative, even when you don't have to. For example, a lot of people
recommend this:

try:
name = record.name
except AttributeError:
name = "Freddy"

instead of this:

if hasattr(record,"name"):
name = record.name
else:
name = "Freddy"


or maybe
name = getattr(record, 'name', 'Freddy')

Kent
Apr 20 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

31 posts views Thread by Chris S. | last post: by
9 posts views Thread by Paul Rubin | last post: by
1 post views Thread by Ryan McLean | last post: by
5 posts views Thread by Nick Flandry | last post: by
6 posts views Thread by Teresa | last post: by
7 posts views Thread by Peter Laan | last post: by
1 post views Thread by Korara | last post: by
???
1 post views Thread by Stoney L | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.