Ignore exceptions

S

SMALLp

Hy. Is there any way to make interrupter ignore exceptions. I'm working
on bigger project and i used to put try catch blocks after writing and
testing code what's boring and it's easy to make mistake. I remember of
something like that in C++ but I cant find anythin like that for python.

SMALLp
 
M

Mike Driscoll

G

Grant Edwards

Hy.
Hi.

Is there any way to make interrupter ignore exceptions.

Nope. Either handle the exceptions or write code that doesn't
generate exceptions.
I'm working on bigger project and i used to put try catch
blocks after writing and testing code

You're getting unhandled exceptions after you've tested your
code? I guess you need to do better testing.
what's boring and it's easy to make mistake. I remember of
something like that in C++ but I cant find anythin like that
for python.

I should hope not. The Python language wouldn't _work_ if the
VM ignored exceptions. Exceptions are used for all sorts of
things besides errors (terminating a loop, exiting a program,
etc.). If exceptions were ignored all sorts of things would
stop working.
 
J

Jonathan Gardner

Hy. Is there any way to make interrupter ignore exceptions. I'm working
on bigger project and i used to put try catch blocks after writing and
testing code what's boring and it's easy to make mistake. I remember of
something like that in C++ but I cant find anythin like that for python.

Hello. Two points with exceptions.

* Only write try blocks when you are actually going to do something
interesting with the exception. Otherwise, let the exception bubble
up.

* If you have unwanted exceptions, fix the root cause of the exception
rather than try to hide the exception. The exception is saying
something is wrong and needs attention. Provide that attention.

I have seen too many people write code in Java that simply masks all
exceptions because they don't want to write the interface to their
functions that describes what exceptions are possible. I have seen
comments around this code saying, "This should always work." Of
course, it doesn't always work and when it doesn't work, they don't
know about it and they don't even know how to tell what went wrong.

The emotion driving this exception masking practice I see in the Java
world is laziness, not correctness. This is not the good form of
laziness (where you want to write good code so you end up doing less
work) but the bad form (where you don't want to work at all).

There is no need to mask exceptions in Python. In fact, it is more
work to mask exceptions, and you should feel bad about all the extra
typing you are doing.

Once again: All try blocks should do something interesting when they
catch an exception. No exception should be ignored or thrown away.

A few sample good uses of try/except blocks:

(1) Do something else if an expected exception occurs.

try:
# There is a good chance an exception will be thrown. If so, I
want to do something else.
d['foo'] += 5
except KeyError:
d['foo'] = 5

(2) Show a friendly error message when an exception occurs over a
significant chunk of the program. (Useful for websites and GUI apps.)

try:
# There is a very complicated piece of code. Any of a million
exceptions could occur.
...
except:
# Show a nicely formatted error message with hints on how to debug
the error.
...

Here are some bad examples:

(BAD)

try:
# I don't know what is happening in here, but it always throws an
exception.
# I don't want to think about it because it makes my brain hurt.
...
except:
pass

(WORSE) The alternate form--try N times, masking the error each time--
is equally bad.

while True:
try:
# Something could go wrong. What could go wrong? Who cares?
...
break
except:
# We'll just keep trying forever....
pass
 
R

Roger Miller

A few sample good uses of try/except blocks:

(1) Do something else if an expected exception occurs.
...
(2) Show a friendly error message when an exception occurs over a
significant chunk of the program. (Useful for websites and GUI apps.)
...

I'd add (3) Clean-up handlers. These don't actually handle the
problem,
they just free resources, close files, etc. before re-raising the
exception
for someone else to worry about.
 
S

Scott David Daniels

Roger said:
I'd add (3) Clean-up handlers. These don't actually handle the
problem, they just free resources, close files, etc. before re-
raising the exception for someone else to worry about.

Ah, but typically these are try/finally blocks. Many can be dealt
with by context mangers in 2.5 or later -- see with_statement.


--Scott David Daniels
(e-mail address removed)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,432
Messages
2,571,680
Members
48,796
Latest member
Greg L.

Latest Threads

Top