Overuse of try/except/else?
Kyle T. Jones
It has been hard for me to determine what would constitute overuse.
Cheers.
James Mills
<onexpa...@evomeryahoodotyouknow.com> wrote:
> It has been hard for me to determine what would constitute overuse.
A rule of thumb I always follow and practice is:
"Let the error lie where it occurred."
or
"Don't hide errors.".
It's good practice to follow IHMO as it makes it easier to find
the source of defects in your function(s). If you constantly
do things like try/except/log then it makes finding the source
harder and may make it harder to identify what caused it.
I favor Test Driven Development (TDD) over Contracts in Python
(as Python is a dynamic programming language) but errors should
be handled and caught by the caller - not the callee.
My 2c, others may have other points of view...
cheers
James
--
-- James Mills
--
-- "Problems are solved by method"
Jean-Michel Pichavant
> On Tue, May 10, 2011 at 10:40 AM, Kyle T. Jones
> <onexpa...@evomeryahoodotyouknow.com> wrote:
>
>>
>
>
> "Let the error lie where it occurred."
>
> or
>
> "Don't hide errors.".
>
> It's good practice to follow IHMO as it makes it easier to find
> the source of defects in your function(s). If you constantly
> do things like try/except/log then it makes finding the source
> harder and may make it harder to identify what caused it.
>
try:
...
except SomeException, exc:
log(exc)
print 'Hello world'
raise # "raise exc" would loose the original stack trace
JM
PS : "code that crashes could use improvement, but incorrect code that
doesn’t crash is a horrible nightmare." (I don't know the author)
Adam Tauno Williams
> It has been hard for me to determine what would constitute overuse.
The chronic problem is under use; so I wouldn't worry much about it.
try/except should occur as often as is required for the application to
either deal gracefully with the condition or report *meaningful* error
messages to the user/administrator.
Hans Georg Schaathun
<awil...@whitemice.org> wrote:
So overuse is really when you cannot do anything meaningful about
the exception. The two interesting questions are really
1. where and when to catch a given exception
2. at what stage of the development cycle catching a particular
(class of) exception should become a priority
There is a potential overuse of exceptions, where they are used for
quite ordinary and frequent (i.e. not exceptional) conditions, and
the information could be passed through the return value instead.
Exceptions is a very flexible, but also rather expensive means of
communications. You can, actually, write any program using raise
instead of return. That would be overuse.
--
:-- Hans Georg
Paul Probert
>
> It has been hard for me to determine what would constitute overuse.
>
> Cheers.
concise code. For example, suppose I call a routine I wrote over and
over, and I have to check for errors on each call. Then you have a long
block of code like:
if err == 0:
x1,err=somefunction(1)
if err == o:
x2,err=somefunction(2)
...
...
but if somefunction just raises an exception on error, then you do
try:
x1=somefunction(1)
x2=somefunction(2)
...
...
except:
blah blah
So for my uses, its handy to let things raise exceptions willy nilly in
the lower level functions, and do the catching in the higher level function.
Paul Probert
James Mills
<jeanm...@sequans.com> wrote:
> You can reraise the exception without loosing the stack trace.
>
> try:
> ...
> except SomeException, exc:
> log(exc)
> print 'Hello world'
> raise # "raise exc" would loose the original stack trace
Valid point :) However I was referring to real experience
where I've seen code that "catches all any any exception"
and simply logs it.
Daniel Kluev
<onexpa...@evomeryahoodotyouknow.com> wrote:
>
> It has been hard for me to determine what would constitute overuse.
>
Good example of abuse is catching KeyboardInterrupt or SystemExit
inside some library code. PycURL does it, and its truly annoying.
--
With best regards,
Daniel Kluev