Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #103749 > unrolled thread
| Started by | Ganesh Pal <ganesh1pal@gmail.com> |
|---|---|
| First post | 2016-02-29 23:51 +0530 |
| Last post | 2016-02-29 22:29 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to comp.lang.python
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: common mistakes in this simple program Ganesh Pal <ganesh1pal@gmail.com> - 2016-02-29 23:51 +0530
Re: common mistakes in this simple program sohcahtoa82@gmail.com - 2016-02-29 11:23 -0800
Re: common mistakes in this simple program Marko Rauhamaa <marko@pacujo.net> - 2016-02-29 22:29 +0200
| From | Ganesh Pal <ganesh1pal@gmail.com> |
|---|---|
| Date | 2016-02-29 23:51 +0530 |
| Subject | Re: common mistakes in this simple program |
| Message-ID | <mailman.35.1456770105.20602.python-list@python.org> |
>> How do we reraise the exception in python , I have used raise not
>> sure how to reraise the exception
>
> raise with no arguments will reraise the exception currently being handled.
>
> except Exception:
> logging.error("something went wrong")
> raise
Thanks Ian for taking time and looking into the code , o k raise
keyword for raising exception is fine .
>>>> assert ret ==0,"ERROR (ret %d): " \
>>>> " \nout: %s\nerr: %s\n" % (ret, out, err)
>>>> except Exception as e:
>>>> print("Failed to run %s got %s" % (cmd, e))
>>>> return False
>>>> return True
>>>>
>>>> def prep_host():
>>>> """
>>>> Prepare clustering
>>>> """
>>>> for cmd in ["ls -al",
>>>> "touch /tmp/file1",
>>>> "mkdir /tmp/dir1"]:
>>>> try:
>>>> if not run_cmd_and_verify(cmd, timeout=3600):
>>>> return False
>>>> except:
>>>
>>> What exceptions are you expecting this to catch? run_cmd_and_verify
>>> already catches any expected exceptions that it raises.
In my case the exception is nothing but the error example if we plan
to run the command say #ifconfig -a and the command fails because of
a type ( say u ran #igconfig -a).
we will the output as
# Failed to run igconfig -a got Error (ret=127)
out :
error: command not found: igconfig
So the execption is the error i.e Error (ret=127) out : error: command
not found: igconfig, Iam fine with this behaviour.
>
> But that exception is already caught by the run_cmd_and_verify
> function, so what exception are you expecting to be caught *here*?
I wanted to run the command in a loop and have a fxn for the pattern
that repeats in this case the function is run_cmd_and_verify , the
only known way to me was using try with expect
I thought I will use try and have pass in except which you don't recommend
for cmd in ["ls -al",
"touch /tmp/file1",
"mkdir /tmp/dir1"]:
try:
if not run_cmd_and_verify(cmd, timeout=3600):
print "running command failed "
return False
except:
pass
> You should virtually never just pass in an exception handler. Either
> handle the exception, or log it and reraise it. If you're going to do
> neither of those things, then don't use a try-except at all.
What alternative do I have other than try-expect ? can try - else be
used for my case?
Regards,
GPal
[toc] | [next] | [standalone]
| From | sohcahtoa82@gmail.com |
|---|---|
| Date | 2016-02-29 11:23 -0800 |
| Message-ID | <45787234-afd1-4e45-a34d-3bf4bdc241f1@googlegroups.com> |
| In reply to | #103749 |
On Monday, February 29, 2016 at 10:21:57 AM UTC-8, Ganesh Pal wrote:
> >> How do we reraise the exception in python , I have used raise not
> >> sure how to reraise the exception
> >
> > raise with no arguments will reraise the exception currently being handled.
> >
> > except Exception:
> > logging.error("something went wrong")
> > raise
>
> Thanks Ian for taking time and looking into the code , o k raise
> keyword for raising exception is fine .
>
> >>>> assert ret ==0,"ERROR (ret %d): " \
> >>>> " \nout: %s\nerr: %s\n" % (ret, out, err)
> >>>> except Exception as e:
> >>>> print("Failed to run %s got %s" % (cmd, e))
> >>>> return False
> >>>> return True
> >>>>
> >>>> def prep_host():
> >>>> """
> >>>> Prepare clustering
> >>>> """
> >>>> for cmd in ["ls -al",
> >>>> "touch /tmp/file1",
> >>>> "mkdir /tmp/dir1"]:
> >>>> try:
> >>>> if not run_cmd_and_verify(cmd, timeout=3600):
> >>>> return False
> >>>> except:
> >>>
> >>> What exceptions are you expecting this to catch? run_cmd_and_verify
> >>> already catches any expected exceptions that it raises.
>
> In my case the exception is nothing but the error example if we plan
> to run the command say #ifconfig -a and the command fails because of
> a type ( say u ran #igconfig -a).
>
> we will the output as
>
> # Failed to run igconfig -a got Error (ret=127)
> out :
> error: command not found: igconfig
>
> So the execption is the error i.e Error (ret=127) out : error: command
> not found: igconfig, Iam fine with this behaviour.
>
>
> >
> > But that exception is already caught by the run_cmd_and_verify
> > function, so what exception are you expecting to be caught *here*?
>
> I wanted to run the command in a loop and have a fxn for the pattern
> that repeats in this case the function is run_cmd_and_verify , the
> only known way to me was using try with expect
>
> I thought I will use try and have pass in except which you don't recommend
>
> for cmd in ["ls -al",
> "touch /tmp/file1",
> "mkdir /tmp/dir1"]:
> try:
> if not run_cmd_and_verify(cmd, timeout=3600):
> print "running command failed "
> return False
> except:
> pass
>
> > You should virtually never just pass in an exception handler. Either
> > handle the exception, or log it and reraise it. If you're going to do
> > neither of those things, then don't use a try-except at all.
>
> What alternative do I have other than try-expect ? can try - else be
> used for my case?
>
> Regards,
> GPal
Every time you say "try-expect", my head wants to explode.
It is called a "try-except" block, because you're using the key words "try" and "except" when you make one.
[toc] | [prev] | [next] | [standalone]
| From | Marko Rauhamaa <marko@pacujo.net> |
|---|---|
| Date | 2016-02-29 22:29 +0200 |
| Message-ID | <878u23cla5.fsf@elektro.pacujo.net> |
| In reply to | #103753 |
sohcahtoa82@gmail.com:
> Every time you say "try-expect", my head wants to explode.
>
> It is called a "try-except" block, because you're using the key words
> "try" and "except" when you make one.
Ah, I remember a Python-based test system idea where the "except"
keyword meant "expect":
try: event()
except user.CloseRequest():
...
except user.SendRequest():
...
except peer.DataIndication():
...
except Timeout():
...
etc.
In the end, though, we came up with something better.
Marko
[toc] | [prev] | [standalone]
Back to top | Article view | comp.lang.python
csiph-web