Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #5044 > unrolled thread

Overuse of try/except/else?

Started by"Kyle T. Jones" <onexpadREMOVE@EVOMERyahoodotyouknow.com>
First post2011-05-09 19:40 -0500
Last post2011-05-22 00:33 +1100
Articles 8 — 7 participants

Back to article view | Back to comp.lang.python


Contents

  Overuse of try/except/else? "Kyle T. Jones" <onexpadREMOVE@EVOMERyahoodotyouknow.com> - 2011-05-09 19:40 -0500
    Re: Overuse of try/except/else? James Mills <prologic@shortcircuit.net.au> - 2011-05-10 11:09 +1000
    Re: Overuse of try/except/else? Jean-Michel Pichavant <jeanmichel@sequans.com> - 2011-05-10 11:34 +0200
    Re: Overuse of try/except/else? Adam Tauno Williams <awilliam@whitemice.org> - 2011-05-10 07:36 -0400
      Re: Overuse of try/except/else? Hans Georg Schaathun <hg@schaathun.net> - 2011-05-10 13:10 +0100
    Re: Overuse of try/except/else? Paul Probert <paulprobert@sbcglobal.net> - 2011-05-10 22:26 -0500
    Re: Overuse of try/except/else? James Mills <prologic@shortcircuit.net.au> - 2011-05-11 13:37 +1000
    Re: Overuse of try/except/else? Daniel Kluev <dan.kluev@gmail.com> - 2011-05-22 00:33 +1100

#5044 — Overuse of try/except/else?

From"Kyle T. Jones" <onexpadREMOVE@EVOMERyahoodotyouknow.com>
Date2011-05-09 19:40 -0500
SubjectOveruse of try/except/else?
Message-ID<iqa1fd$4l0$1@dont-email.me>
It has been hard for me to determine what would constitute overuse.

Cheers.

[toc] | [next] | [standalone]


#5045

FromJames Mills <prologic@shortcircuit.net.au>
Date2011-05-10 11:09 +1000
Message-ID<mailman.1365.1304989764.9059.python-list@python.org>
In reply to#5044
On Tue, May 10, 2011 at 10:40 AM, Kyle T. Jones
<onexpadREMOVE@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"

[toc] | [prev] | [next] | [standalone]


#5061

FromJean-Michel Pichavant <jeanmichel@sequans.com>
Date2011-05-10 11:34 +0200
Message-ID<mailman.1376.1305020059.9059.python-list@python.org>
In reply to#5044
James Mills wrote:
> On Tue, May 10, 2011 at 10:40 AM, Kyle T. Jones
> <onexpadREMOVE@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.
>   
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

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)

[toc] | [prev] | [next] | [standalone]


#5065

FromAdam Tauno Williams <awilliam@whitemice.org>
Date2011-05-10 07:36 -0400
Message-ID<mailman.1380.1305027477.9059.python-list@python.org>
In reply to#5044
On Mon, 2011-05-09 at 19:40 -0500, Kyle T. Jones wrote:
> 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.

[toc] | [prev] | [next] | [standalone]


#5067

FromHans Georg Schaathun <hg@schaathun.net>
Date2011-05-10 13:10 +0100
Message-ID<3imn98-6r3.ln1@svn.schaathun.net>
In reply to#5065
On Tue, 10 May 2011 07:36:42 -0400, Adam Tauno Williams
  <awilliam@whitemice.org> wrote:
:  On Mon, 2011-05-09 at 19:40 -0500, Kyle T. Jones wrote:
: > 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.

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

[toc] | [prev] | [next] | [standalone]


#5089

FromPaul Probert <paulprobert@sbcglobal.net>
Date2011-05-10 22:26 -0500
Message-ID<q7cp98-qu2.ln1@giganews.com>
In reply to#5044
On 05/09/2011 07:40 PM, Kyle T. Jones wrote:
>
> It has been hard for me to determine what would constitute overuse.
>
> Cheers.
Well, for me the power of exceptions is that it lets me write much more 
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

[toc] | [prev] | [next] | [standalone]


#5091

FromJames Mills <prologic@shortcircuit.net.au>
Date2011-05-11 13:37 +1000
Message-ID<mailman.1391.1305085100.9059.python-list@python.org>
In reply to#5044
On Tue, May 10, 2011 at 7:34 PM, Jean-Michel Pichavant
<jeanmichel@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.

cheers
James

-- 
-- James Mills
--
-- "Problems are solved by method"

[toc] | [prev] | [next] | [standalone]


#5919

FromDaniel Kluev <dan.kluev@gmail.com>
Date2011-05-22 00:33 +1100
Message-ID<mailman.1878.1305984816.9059.python-list@python.org>
In reply to#5044
On Tue, May 10, 2011 at 11:40 AM, Kyle T. Jones
<onexpadREMOVE@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

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web