Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #103749 > unrolled thread

Re: common mistakes in this simple program

Started byGanesh Pal <ganesh1pal@gmail.com>
First post2016-02-29 23:51 +0530
Last post2016-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.


Contents

  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

#103749 — Re: common mistakes in this simple program

FromGanesh Pal <ganesh1pal@gmail.com>
Date2016-02-29 23:51 +0530
SubjectRe: 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]


#103753

Fromsohcahtoa82@gmail.com
Date2016-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]


#103757

FromMarko Rauhamaa <marko@pacujo.net>
Date2016-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