«

> > Please do NOT catch BaseException, since that is the wrong thing to do.

>
> I would agree if you had said "in production code".
>
> If you are investigating why a third-party function is stopping your
> interpreter, then catching BaseException may tell you that the code
> is raising the wrong kind of Exception. Once you know whatkind the
> function is raising, you should catch only that particularexcpetion
> subclass.


I would say the opposite. In production code usually I want it
to recover, log as much information as I need (including sending
any notifications), and NOT just die.

In development, not catching the exception will give me a full
trace back automatically. Why bother with trying to catch and
print something when the interpreter will do it for me? Not
to mention that removes any hassle of trying to catch the
"right" exception or figuring out the best way to print it.
I suppose if there are argumentson the exception that were not
printed then I might want to catch it,but has been rare
in my experience.

Ramit

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness of information, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.

On Sat, Jul 14, 2012 at 3:08 AM, Prasad, Ramit
<> wrote:
> I would say the opposite. In production code usually I want it
> to recover, log as much information as I need (including sending
> any notifications), and NOT just die.
>
> In development, not catching the exception will give me a full
> trace back automatically.

Here's another take on the matter. In development, your script is your
execution unit, so you let the interpreter print out your tracebacks.
In production, there will usually be one, maybe two subunits (for
instance, a TCP-based server might have the socket connection as an
execution unit, and possibly a command parser inside that), and at the
top of that subunit, you have a broad exception handler that resets
that one unit (goes back and accepts another client, or waits for
another command). Otherwise, wide-scope exception handling is usually
a bad thing.

ChrisA