On Thu, Aug 02, 2018 at 12:19:41PM -0700, Marc Tompkins wrote:
> What you want in that case is an assertion:
>
> try:
> assert type(uvc)==float
> except AssertionError as e:
> print(e, msg)
>
> An assertion says "The following statement is True. If it isn't, I'm going
> to throw an exce
On 02/08/18 15:29, Shall, Sydney wrote:
> uvc = 2
> msg = "Bad argument provided, the value of uvc must be a float."
>
> try:
> type(uvc) == float
> except TypeError as e:
> print(e, msg)
The try block contains an expression that will always evaluate
to True or False and thus never rai
try... except is meant to catch errors: places where your program would
otherwise crash. It does NOT work as a truth check.
In your example:
> try:
> type(uvc) == float
> except TypeError as e:
> print(e, msg)
>
> "type(uvc)==float" resolves to a standalone True or False, not an
exception
On 2 August 2018 at 15:29, Shall, Sydney wrote:
>
> try:
> type(uvc) == float
> except TypeError as e:
> print(e, msg)
Let's try this interactively:
>>> uvc = 2
>>> type(uvc)
>>> type(uvc) == float
False
So calling type(uvc) doesn't raise an error. It returns the type
"int". You then c
MAC OS X 10.13.6
Anaconda python 3.6.5
Anaconda IPython 6.4.0
I am having difficulty in using the try, except form.
I copy and paste a minimal program to illustrate my problem.
#!/usr/bin/env python3
# -*- coding: utf-8 -*-
"""
Created on Thu Aug 2 15:41:15 2018
@author: sydney
"""
uvc = 2
On Wed, May 22, 2013 at 8:47 PM, Steven D'Aprano wrote:
> On 23/05/13 02:09, boB Stepp wrote:
>
>> I would like to ask some general questions here. Problems can arise
>> from bugs in the operating system, bugs in the programming language(s)
>> being used, bugs in packages/modules being used, bugs
On 23/05/13 02:09, boB Stepp wrote:
I would like to ask some general questions here. Problems can arise
from bugs in the operating system, bugs in the programming language(s)
being used, bugs in packages/modules being used, bugs in any third
party packages being used, etc. Also, whenever any one
On 05/22/2013 03:03 PM, Albert-Jan Roskam wrote:
Subject: Re: [Tutor] try..except - what about that ton of **Error statements?
On 23/05/13 02:09, boB Stepp wrote:
I was not aware that hardware damage could be caused by poor
programming. I am curious; can you give some examples of how
> Subject: Re: [Tutor] try..except - what about that ton of **Error statements?
>
> On 23/05/13 02:09, boB Stepp wrote:
>
>> I was not aware that hardware damage could be caused by poor
>> programming. I am curious; can you give some examples of how this
>> mi
On Wed, May 22, 2013 at 9:50 AM, boB Stepp wrote:
> I guess I'll pick the first alternative. However, this brings to mind
> my biggest gripe as a user of software, particularly here at work
> where the programmer obviously has no medical background: cryptic
> error messages that might be meaningf
On 23/05/13 02:09, boB Stepp wrote:
I was not aware that hardware damage could be caused by poor
programming. I am curious; can you give some examples of how this
might occur?
Does your computer have a DVD drive? Or Blu-Ray? Is it region-locked? Some region-locked
drives let you change the re
On Wed, May 22, 2013 at 9:45 AM, Steven D'Aprano wrote:
> On 22/05/13 23:31, boB Stepp wrote:
>>
>> On Wed, May 22, 2013 at 7:50 AM, Steven D'Aprano
>> wrote:
[...]
>>> 3) your job as a programmer is *not* to stop your program from raising an
>>> error, but to make it behave correctly -- someti
Thanks, Steve, for your last two posts. You have made things much
clearer for me.
On Wed, May 22, 2013 at 9:49 AM, Steven D'Aprano wrote:
> On 22/05/13 23:37, boB Stepp wrote:
>>
>> On Wed, May 22, 2013 at 8:07 AM, Steven D'Aprano
>> wrote:
>>>
[...]
>>
>> Being a novice programmer, I am inter
On 22/05/13 23:37, boB Stepp wrote:
On Wed, May 22, 2013 at 8:07 AM, Steven D'Aprano wrote:
On 22/05/13 16:20, Jim Mooney wrote:
[...}
A very important quote from Chris Smith:
"I find it amusing when novice programmers believe their main job is
preventing programs from crashing. ... More
On 22/05/13 23:31, boB Stepp wrote:
On Wed, May 22, 2013 at 7:50 AM, Steven D'Aprano wrote:
On 22/05/13 15:46, Jim Mooney wrote:
[...]
But don't do this in real code! In real code, the rules you should apply
are:
1) never hide programming errors by catching exceptions;
2) errors shoul
On Wed, May 22, 2013 at 8:07 AM, Steven D'Aprano wrote:
> On 22/05/13 16:20, Jim Mooney wrote:
>>>
[...}
> A very important quote from Chris Smith:
>
> "I find it amusing when novice programmers believe their main job is
> preventing programs from crashing. ... More experienced programmers reali
On Wed, May 22, 2013 at 7:50 AM, Steven D'Aprano wrote:
> On 22/05/13 15:46, Jim Mooney wrote:
>>
[...]
>
> But don't do this in real code! In real code, the rules you should apply
> are:
>
>
> 1) never hide programming errors by catching exceptions;
>
> 2) errors should only be caught if you ca
On 22/05/13 16:20, Jim Mooney wrote:
Keep the try block small. For example if it's for a call to
open(filename, "r") the only possible errors (assuming correct syntax)
are NameError for using an undefined variable and IOError for
specifying a file which doesnt exist.
Jim, I don't know who you
On 22/05/13 15:46, Jim Mooney wrote:
I'm looking at Try..Except
Try:
Except SomethingError as err:
The list of error statements is huge. How do I know which error
statement to put in place of SomethingError (or multiple errors for
that matter)? Or is it best to just leave Something
On Tue, May 21, 2013 at 11:25 PM, Bod Soutar wrote:
> On 22 May 2013 07:20, Jim Mooney wrote:
> >> Keep the try block small. For example if it's for a call to
> >> open(filename, "r") the only possible errors (assuming correct syntax)
> >> are NameError for using an undefined variable and IOErro
On 22 May 2013 07:20, Jim Mooney wrote:
>> Keep the try block small. For example if it's for a call to
>> open(filename, "r") the only possible errors (assuming correct syntax)
>> are NameError for using an undefined variable and IOError for
>> specifying a file which doesnt exist.
>
> Thanks. Sin
> Keep the try block small. For example if it's for a call to
> open(filename, "r") the only possible errors (assuming correct syntax)
> are NameError for using an undefined variable and IOError for
> specifying a file which doesnt exist.
Thanks. Since I'm new at this the error lists I saw just ha
I'm looking at Try..Except
Try:
Except SomethingError as err:
The list of error statements is huge. How do I know which error
statement to put in place of SomethingError (or multiple errors for
that matter)? Or is it best to just leave SomethingError blank until I
know more? ( I have a
"Steven D'Aprano" wrote
Wrapping an atomic block of code, so long as it actually *can* be
treated as atomic (including backing out any changes if it fails),
is a good use of try...except.
That's exactly what I meant by atomic. A (smallish) group of
instructions
that must be treated as a gro
Alan Gauld wrote:
However, using exceptions like if/else blocks is bad practice.
I'm afraid I disagree strongly with that!
You need to use them like a commit in SQL - to protect a whole
block of code. Putting try/except around every line of code
defeats the purpose, wrap atomic blocks of cod
Steven many thanks for this useful hint!
I will modify my code.
Many thanks!
Regards
Karim
On 01/10/2011 11:32 AM, Steven D'Aprano wrote:
Karim wrote:
Thank you Steven, Modulok and Alan for your precious and detailed
explanations!
I understood that I must not overuse try-except statement
Karim wrote:
Thank you Steven, Modulok and Alan for your precious and detailed
explanations!
I understood that I must not overuse try-except statement and usually
when the exception could happen exceptionally.
By the way I have this piece of code using elementTree standard module
and accord
Thanks Alan this reassures me!
Regards
Karim
On 01/10/2011 10:39 AM, ALAN GAULD wrote:
By the way I have this piece of code using elementTree standard
module
and according to Alan this is bad code I guess:
Which just proves there are no absolute rules in programming :-)
*try
By the way I have this piece of code using elementTree standard module
>and according to Alan this is bad code I guess:
>
>
Which just proves there are no absolute rules in programming :-)
try: devdb.setDescription(dev.attrib['description'])
>except KeyError: pass
>try: devdb.setSymbolName
Thank you Steven, Modulok and Alan for your precious and detailed
explanations!
I understood that I must not overuse try-except statement and usually
when the exception could happen exceptionally.
By the way I have this piece of code using elementTree standard module
and according to Alan th
"Karim" wrote
I am using more and more try except statement. But I discussed with
a very experienced C++ programmer.
And he told me that at least in C++ using too many try -catch
statements are making the code slower.
That's true, but Bjarne Stroustrup put them in for a reason - and they
are
On 1/9/11, Karim wrote:
>
> Hello all,
>
> I am using more and more try except statement. But I discussed with a
> very experienced C++ programmer.
> And he told me that at least in C++ using too many try -catch statements
> are making the code slower. And it should
> does the same for python (C i
Karim wrote:
Hello all,
I am using more and more try except statement. But I discussed with a
very experienced C++ programmer.
And he told me that at least in C++ using too many try -catch statements
are making the code slower. And it should
does the same for python (C implementation).
He
Hello all,
I am using more and more try except statement. But I discussed with a
very experienced C++ programmer.
And he told me that at least in C++ using too many try -catch statements
are making the code slower. And it should
does the same for python (C implementation). My simple question:
On Sun, Dec 7, 2008 at 12:25 PM, Lie Ryan <[EMAIL PROTECTED]> wrote:
> texts = ["a = %s\n" % plan.a,
> "b = %s\n" % plan.b,
> "c = %s\n" % plan.c,
> "d = %s\n" % plan.d
>]
>
> for text in texts:
>try:
>fo.write(text)
>except AttributeError:
>
On Mon, 01 Dec 2008 20:44:20 -0500, Bryan Fodness wrote:
> I would like to use a try except to see if a value exists. But, when I
> use the following, if a does not exist it exits. I understand why this
> does this, but is there a way to get b,c, and d if a does not exist
> without using a try e
Bryan Fodness wrote:
I would like to use a try except to see if a value exists. But, when
I use the following, if a does not exist it exits. I understand why
this does this, but is there a way to get b,c, and d if a does not
exist without using a try except for every statement?
try:
fo
On 02/12/2008, Bryan Fodness <[EMAIL PROTECTED]> wrote:
> I would like to use a try except to see if a value exists. But, when I use
> the following, if a does not exist it exits. I understand why this does
> this, but is there a way to get b,c, and d if a does not exist without using
> a try exc
I would like to use a try except to see if a value exists. But, when I use
the following, if a does not exist it exits. I understand why this does
this, but is there a way to get b,c, and d if a does not exist without using
a try except for every statement?
try:
fo.write("a = %s\n" %plan.a)
> I'm playing around with try: and except: i have a code like this
>try:
>bibl=os.listdir("c:\\klientdata\\")
>except:
>wx.MessageBox("Kunde inte läsa käll ...
>
> So far i get how to use it but i would like to be able to execute
> the try block again after
On 09/08/06, Magnus Wirström <[EMAIL PROTECTED]> wrote:
> Hi
>
> I'm playing around with try: and except: i have a code like this
>try:
>bibl=os.listdir("c:\\klientdata\\")
>except:
>wx.MessageBox("Kunde inte läsa käll
> biblioteket.","Säkerhetskopiering",wx.
Hi
I'm playing around with try: and except: i have a code like this
try:
bibl=os.listdir("c:\\klientdata\\")
except:
wx.MessageBox("Kunde inte läsa käll
biblioteket.","Säkerhetskopiering",wx.OK|wx.ICON_ERROR)
(yeah ... it's swedish :) )
So far i get how t
D]
Sent: Wednesday, August 24, 2005 2:29 PM
To: Tutor
Subject: Re: [Tutor] try except continue (fwd)
-- Forwarded message --
Date: Wed, 24 Aug 2005 11:24:44 -0700
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Danny Yoo <[EMAIL PROTECTED]>
Subject: Re: [Tutor] try excep
-- Forwarded message --
Date: Wed, 24 Aug 2005 11:24:44 -0700
From: [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: Danny Yoo <[EMAIL PROTECTED]>
Subject: Re: [Tutor] try except continue
hi Danny, I finally had a chance to review your explanation of
continue you wrote a
-- code here -
def f():
if error:
raise ValueError
else:
print "I'm in f()"
def g():
print "I'm in g()"
def h():
error = True
print "error is: ", error
n = 5
while n:
print "n is: ", n
n -= 1
try:
f()
g()
except ValueError:
hi guys, so I've been running through Alan's code, and for a while I
suspected that the try block must be the first line of code after the
loop in order to be executed. The reason I say this is I wanted to
see for myself Alan's assertion that the continue skips to the next
iteration, instead of co
Hi!
I think you just want to execute the rest of the function's in someProcedure().
Perhaps this could be the solution, what you want:
>>> def someProcedure():
... for func in [ someFunc00, someFunc01, someFunc02, someFunc03 ]:
... try:
... func()
...
> I don't believe I am ignoring the error.
If you log it and then immediately continue then you are ignoring
it so far as the program is concerned. The logging is only
significant to you after the program completes.
> the error and pick up where it left off and keep going.
> I gather you think th
> I see the continue statement as a way for me to do this, and thus
> intimately linked with exception handling.
Hi Tpc,
I think you're getting too caught up with the word "continue" and its
concept as you use it in human language, rather than what it really does
in the Python language.
I sho
hi Alan and Danny,
I think I understand what you guys are saying. I don't believe I am
ignoring the error. Ideally what I'd like is for the procedural
program to run through its steps and if it encounters an error, to log
the error and pick up where it left off and keep going. I gather you
thin
On Thu, 28 Jul 2005 [EMAIL PROTECTED] wrote:
> ideally what I'd like is for my procedural program, when it runs through
> its steps and encounters an error, to log the error and pick up where it
> left off and keep going.
>
> so for the execution of someProcedure(), I want it to print the error
> program, when it runs through its steps and encounters an error, to
> log
> the error and pick up where it left off and keep going. According
> to this
> link, 'continue' is allowed within an except or finally:
Thats true but only if the try block is inside a loop.
Consider:
error = True
de
hi Danny, well from my previous message:
ideally what I'd like is for my procedural program, when it runs
through its steps and encounters an error, to log the error and pick
up where it left off and keep going.
so for the execution of someProcedure(), I want it to print the error
and continue ru
On Thu, 28 Jul 2005 [EMAIL PROTECTED] wrote:
> import testTryCatch
> try:
> testTryCatch.someProcedure()
> except:
> print "encountered error"
> continue
>
> but I get the following error:
>
> SyntaxError: 'continue' not properl
hey guys, so I've been trying to get my head around the try except
statement in Python, and ideally what I'd like is for my procedural
program, when it runs through its steps and encounters an error, to log
the error and pick up where it left off and keep going. According to this
link, 'continue'
55 matches
Mail list logo
