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


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

Re: usage of try except for review.

Started byDennis Lee Bieber <wlfraed@ix.netcom.com>
First post2016-02-29 11:40 -0500
Last post2016-02-29 11:40 -0500
Articles 1 — 1 participant

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: usage of try except for review. Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2016-02-29 11:40 -0500

#103732 — Re: usage of try except for review.

FromDennis Lee Bieber <wlfraed@ix.netcom.com>
Date2016-02-29 11:40 -0500
SubjectRe: usage of try except for review.
Message-ID<mailman.24.1456764004.20602.python-list@python.org>
On Mon, 29 Feb 2016 15:33:18 +0530, Ganesh Pal <ganesh1pal@gmail.com>
declaimed the following:

>Iam on python 2.6 and Linux , need your suggestion on the usage of try
>and except in this program
>
>#!/usr/bin/env python
>
>
>"""
>"""
>import os
>import shlex
>import subprocess
>import sys
>import time
>import logging
>import run
>import pdb
>
>def run_cmd_and_verify(cmd, timeout=1000):
>
>    try:
>        out, err, ret = run(cmd, timeout=timeout)
>        assert ret ==0,"ERROR (ret %d): " \
>                " \nout: %s\nerr: %s\n" % (ret, out, err)

	If the assert triggers, it will generate an exception

	But this doesn't look like a place where an assert is really desirable,
especially when you are inside an exception trap. At least in my viewpoint
-- asserts are 1) not something for regular logic (if you run the script
with some optimization, the assert statements are "removed"; 2) they should
more be used to confirm that the entry criteria were met.

	Ask yourself: Will my program still work if I remove all the assert
statements. If the answer is "No", then you should not be using an assert.

	Can your "run()" raise an exception? Since you never show it to us we
can't tell. And if it can, which ones? However, checking a return code is
not an exceptional condition -- that's expected logic.

def rcav(cmd, to=1000):
	assert cmd is not Null, "No command provided in rcav"
	try:
		out, err, ret = run(cmd, to)
	except Exception as e:
		logging.exception("function run() failed:")
		#I need to test to see how much of the exception info is
		#automatic
	if not ret:
		logging.error("cmd '%s' failed", cmd)
	return ret	#0 is false, non-0 is true

	Note that I do not trap the assert exception -- this is the type of
event that the caller needs to see.

>        try:
>            if not run_cmd_and_verify(cmd, timeout=3600):

	Since your version of rcav() always trapped exceptions internally, this
call will never raise an exception, so using a try: block is meaningless

>                return False

	And your conditional basically comes down to:

	if False:
		return False:


>        except:
>           logging.error("Some meaningful message")
>    logging.info("Setup and Creation ....Done !!!")

	But you fall off and return Null on success...

>    #
>    cmd = "run_scan"
>    out, err, ret = run(cmd)
>
>    for cmd in ["create_data.py -nfs ",
>                "validate.py -30 "]:

	Spawning processes to run Python files seems perverse.

	You should instead write create_data.py and validate.py so that you can
do

	import create_data
	import validate


	create.data.main("-nfs")
	validate.main(-30)

-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web