On 30/01/2015 08:10, Mark Lawrence wrote:
On 30/01/2015 06:16, Marko Rauhamaa wrote:
Ian Kelly :
At least use "except Exception" instead of a bare except. Do you
really want things like SystemExit and KeyboardInterrupt to get turned
into 0?
How about:
==
try
On Fri, Jan 30, 2015 at 8:56 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> Like I suggested earlier, just don't catch the inner exception at all.
>> The result will be both exceptions propagated, chained in the proper
>> order.
>
> Depends on the situation.
Like what? If you want to specifically p
Ian Kelly :
> Like I suggested earlier, just don't catch the inner exception at all.
> The result will be both exceptions propagated, chained in the proper
> order.
Depends on the situation.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Sat, Jan 31, 2015 at 2:42 AM, Ian Kelly wrote:
> Like I suggested earlier, just don't catch the inner exception at all.
> The result will be both exceptions propagated, chained in the proper
> order.
So many MANY times, the best thing to do with unrecognized exceptions
is simply to not catch t
On Fri, Jan 30, 2015 at 8:30 AM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> The bare raise re-raises the most recent exception that is being
>> handled. The "raise e" raises that exception specifically, which is
>> not the most recent in the case of a secondary exception.
>
> Scary. That affects all
Ian Kelly :
> The bare raise re-raises the most recent exception that is being
> handled. The "raise e" raises that exception specifically, which is
> not the most recent in the case of a secondary exception.
Scary. That affects all finally clauses. Must remember that.
The pitfall is avoided by
On Fri, Jan 30, 2015 at 3:00 AM, Marko Rauhamaa wrote:
> Marko Rauhamaa :
>
Surprisingly this variant could raise an unexpected exception:
==
try:
do_interesting_stuff()
except ValueError:
try:
Marko Rauhamaa :
>>> Surprisingly this variant could raise an unexpected exception:
>>>
>>> ==
>>> try:
>>> do_interesting_stuff()
>>> except ValueError:
>>> try:
>>> log_it()
>>> finally:
>>> raise
>>>
On Fri, Jan 30, 2015 at 2:02 AM, Marko Rauhamaa wrote:
> Mark Lawrence :
>
>> On 30/01/2015 06:16, Marko Rauhamaa wrote:
>>> How about:
>>>
>>> ==
>>> try:
>>> do_interesting_stuff()
>>> except ValueError:
>>> try:
>>> log_it()
>
On Thu, Jan 29, 2015 at 11:16 PM, Marko Rauhamaa wrote:
> Ian Kelly :
>
>> At least use "except Exception" instead of a bare except. Do you
>> really want things like SystemExit and KeyboardInterrupt to get turned
>> into 0?
>
> How about:
>
> ==
> try:
> do
Mark Lawrence :
> On 30/01/2015 06:16, Marko Rauhamaa wrote:
>> How about:
>>
>> ==
>> try:
>> do_interesting_stuff()
>> except ValueError:
>> try:
>> log_it()
>> except:
>> pass
>> raise
>> ===
On 30/01/2015 06:16, Marko Rauhamaa wrote:
Ian Kelly :
At least use "except Exception" instead of a bare except. Do you
really want things like SystemExit and KeyboardInterrupt to get turned
into 0?
How about:
==
try:
do_interesting_stuff()
exce
I would usually just log the stack trace so that I would still know that
something bad happened while the app looks okay.
On Fri, Jan 30, 2015 at 1:17 AM, Mark Lawrence
wrote:
> The author is quite clear on his views here https://realpython.com/blog/
> python/the-most-diabolical-python-antipatte
On Jan 29, 2015, at 18:36, Skip Montanaro wrote:
> There are the occasional instance where I need to recover
> from an exception no matter what caused it.
I had the same need, a while ago, when working on a CherryPy webapp which uses
a BackgroundTask to parse user-uploaded data and image files
Ian Kelly :
> At least use "except Exception" instead of a bare except. Do you
> really want things like SystemExit and KeyboardInterrupt to get turned
> into 0?
How about:
==
try:
do_interesting_stuff()
except ValueError:
try:
log_
On Fri, Jan 30, 2015 at 4:32 AM, Tim Chase
wrote:
> I have one that I call int0()
> that is my "give me a freakin' int" function which is something like
>
> def int0(val):
> try:
> return int(val)
> except:
> return 0
>
> because I deal with a lot of CSV data from client/vend
On Thu, Jan 29, 2015 at 10:32 AM, Tim Chase
wrote:
> On 2015-01-29 17:17, Mark Lawrence wrote:
>> The author is quite clear on his views here
>> https://realpython.com/blog/python/the-most-diabolical-python-antipattern/
>> but what do you guys and gals think?
>
> I just read that earlier today and
On 2015-01-29 17:17, Mark Lawrence wrote:
> The author is quite clear on his views here
> https://realpython.com/blog/python/the-most-diabolical-python-antipattern/
> but what do you guys and gals think?
I just read that earlier today and agree for the most part. The only
exception (pun only pa
On 01/29/2015 09:36 AM, Skip Montanaro wrote:
> On Thu, Jan 29, 2015 at 11:17 AM, Mark Lawrence
> wrote:
>>
>> ... but what do you guys and gals think?
>
> I saw that blog referenced elsewhere a day or two ago. I think he's
> correct. There are the occasional instance where I need to recover
> f
On Thu, Jan 29, 2015 at 11:17 AM, Mark Lawrence wrote:
>
> ... but what do you guys and gals think?
I saw that blog referenced elsewhere a day or two ago. I think he's
correct. There are the occasional instance where I need to recover
from an exception no matter what caused it. In cases where I f
20 matches
Mail list logo
