exceptions

Discussion in 'Python' started by Calvin Spealman, May 31, 2004.

  1. Peter Hansen wrote:
    > Zunbeltz Izaola wrote:
    >> I've trid this, but the problem is that this finished the try block.
    >> I want to continue executing the try block from the point the
    >> exception was raised.

    >
    > Not possible except, perhaps, with a significant amount of
    > working involving sys.settrace(). I think you need to find
    > another way to solve the problem.


    Have to admit tho, a continue feature might be useful. Some languages have
    this, don't they? The thing is, Where exactly to continue? Should you retry
    whatever raised the exception, continue just after it, at the beginning of
    that line, or what?
     
    Calvin Spealman, May 31, 2004
    #1
    1. Advertising

  2. Hi,

    I've the following problem with try/exception.
    I've a try block that will raise some exceptions.
    I want the program to ignore this exceptions completely.
    Is it possible?

    Thanks in advance

    Zunbeltz

    --
    Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
    dotes
    Materia Kondentsatuaren Fisika Saila |
    Zientzia eta Teknologia Fakultatea | Phone: 34946015326
    Euskal Herriko Unibertsitatea |
    PK 644 | Fax: 34 944648500
    48080 Bilbo (SPAIN) |
     
    Zunbeltz Izaola, May 31, 2004
    #2
    1. Advertising

  3. Calvin Spealman

    Jeff Epler Guest

    Use "pass" as the body of the "except:" block. For example:

    def put(s, i, j):
    """Store j at s, or do nothing if s is not that long"""
    try:
    s = j
    except IndexError:
    pass

    >>> l = [1, 2, 3]
    >>> put(l, 1, "hi")
    >>> put(l, 4, "bye")
    >>> l

    [1, 'hi', 3]

    Jeff

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (GNU/Linux)

    iD8DBQFAuyCpJd01MZaTXX0RAgFJAJ4sSYM9XKWuzJk9vzXGMgnU2EhfZgCfR70/
    YjRBsk9yMptdSNWPodl46vQ=
    =hQG9
    -----END PGP SIGNATURE-----
     
    Jeff Epler, May 31, 2004
    #3
  4. Calvin Spealman

    Peter Hansen Guest

    Zunbeltz Izaola wrote:
    > I've the following problem with try/exception.
    > I've a try block that will raise some exceptions.
    > I want the program to ignore this exceptions completely.
    > Is it possible?


    In the following, all exceptions will be ignored:

    try:
    # something that raises exceptions
    except:
    pass

    This is definitely *not* a recommended way to write software,
    however. You should really understand what you are doing before
    writing code this way.

    -Peter
     
    Peter Hansen, May 31, 2004
    #4
  5. Calvin Spealman

    Brian Gough Guest

    Zunbeltz Izaola <> writes:

    > I've the following problem with try/exception.
    > I've a try block that will raise some exceptions.
    > I want the program to ignore this exceptions completely.
    > Is it possible?


    You can use an empty "except:" to catch all exceptions and ignore them,

    try:
    # your code
    except:
    pass

    See the Python tutorial or language reference manual for details.

    --
    Brian Gough

    Network Theory Ltd,
    Publishing the Python Manuals --- http://www.network-theory.co.uk/
     
    Brian Gough, May 31, 2004
    #5
  6. Peter Hansen <> writes:

    > Zunbeltz Izaola wrote:
    > > I've the following problem with try/exception.
    > > I've a try block that will raise some exceptions.
    > > I want the program to ignore this exceptions completely. Is it
    > > possible?

    >
    > In the following, all exceptions will be ignored:
    >
    > try:
    > # something that raises exceptions
    > except:
    > pass
    >


    I've trid this, but the problem is that this finished the try block.
    I want to continue executing the try block from the point the
    exception was raised.

    > This is definitely *not* a recommended way to write software,
    > however. You should really understand what you are doing before
    > writing code this way.
    >


    I know. I need this feature for testing. I will desable it later.

    Zunbeltz

    > -Peter


    --
    Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
    dotes
    Materia Kondentsatuaren Fisika Saila |
    Zientzia eta Teknologia Fakultatea | Phone: 34946015326
    Euskal Herriko Unibertsitatea |
    PK 644 | Fax: 34 944648500
    48080 Bilbo (SPAIN) |
     
    Zunbeltz Izaola, May 31, 2004
    #6
  7. Calvin Spealman

    Peter Hansen Guest

    Zunbeltz Izaola wrote:
    > Peter Hansen <> writes:
    >>Zunbeltz Izaola wrote:
    >>
    >>>I've the following problem with try/exception.
    >>>I've a try block that will raise some exceptions.
    >>>I want the program to ignore this exceptions completely. Is it
    >>>possible?

    >>
    >>In the following, all exceptions will be ignored:
    >>
    >>try:
    >> # something that raises exceptions
    >>except:
    >> pass

    >
    > I've trid this, but the problem is that this finished the try block.
    > I want to continue executing the try block from the point the
    > exception was raised.


    Not possible except, perhaps, with a significant amount of
    working involving sys.settrace(). I think you need to find
    another way to solve the problem.

    What you are trying to do is not something that other people
    who do unit testing seem to have to do. Why do you think
    you need to actually *disable* exceptions entirely in order
    to test this code? Perhaps the code needs to be restructured?

    -Peter
     
    Peter Hansen, May 31, 2004
    #7
  8. Peter Hansen <> writes:

    > Zunbeltz Izaola wrote:
    > > Peter Hansen <> writes:
    > >>Zunbeltz Izaola wrote:
    > >>
    > >>>I've the following problem with try/exception.
    > >>>I've a try block that will raise some exceptions.
    > >>>I want the program to ignore this exceptions completely. Is it
    > >>>possible?
    > >>
    > >>In the following, all exceptions will be ignored:
    > >>
    > >>try:
    > >> # something that raises exceptions
    > >>except:
    > >> pass

    > > I've trid this, but the problem is that this finished the try block.
    > > I want to continue executing the try block from the point the
    > > exception was raised.

    >
    > Not possible except, perhaps, with a significant amount of
    > working involving sys.settrace(). I think you need to find
    > another way to solve the problem.
    >
    > What you are trying to do is not something that other people
    > who do unit testing seem to have to do. Why do you think
    > you need to actually *disable* exceptions entirely in order
    > to test this code? Perhaps the code needs to be restructured?


    Possibly the code should be restructered, and re-designed; there is
    always room for imporovement. But what I'm doing is not unittest. My
    program is controling and instrument (an x-ray powder
    diffractometer) and some parts of the instrument are not working for
    the moment, so i want to disable all error i get from this instrument
    (are coded like exceptions)

    Zunbeltz
    >
    > -Peter


    --
    Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
    dotes
    Materia Kondentsatuaren Fisika Saila |
    Zientzia eta Teknologia Fakultatea | Phone: 34946015326
    Euskal Herriko Unibertsitatea |
    PK 644 | Fax: 34 944648500
    48080 Bilbo (SPAIN) |
     
    Zunbeltz Izaola, May 31, 2004
    #8
  9. Zunbeltz Izaola wrote:

    > Possibly the code should be restructered, and re-designed; there is
    > always room for imporovement. But what I'm doing is not unittest. My
    > program is controling and instrument (an x-ray powder
    > diffractometer) and some parts of the instrument are not working for
    > the moment, so i want to disable all error i get from this instrument
    > (are coded like exceptions)


    What I usually do in comparable situations is to write STUB code for
    the parts of the system that don't work yet.
    Write your stub code so that it does nothing, but doesn't raise any
    exceptions too. The only thing you then have to do is write the rest
    of the code as you would have done, and once the Stubbed parts work,
    replace the stub code with the real code.

    --Irmen
     
    Irmen de Jong, May 31, 2004
    #9
  10. Calvin Spealman wrote:
    > ...
    > Have to admit tho, a continue feature might be useful. Some languages have
    > this, don't they? The thing is, Where exactly to continue? Should you retry
    > whatever raised the exception, continue just after it, at the beginning of
    > that line, or what?
    >
    >

    See this older thread:
    <http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>

    Xerox's experience (in deliberately removing the "continue from
    exception" language feature) I found very instructive.

    -Scott David Daniels
     
    Scott David Daniels, May 31, 2004
    #10
  11. Calvin Spealman

    John J. Lee Guest

    Irmen de Jong <> writes:

    > Zunbeltz Izaola wrote:
    >
    > > Possibly the code should be restructered, and re-designed; there is
    > > always room for imporovement. But what I'm doing is not unittest. My
    > > program is controling and instrument (an x-ray powder
    > > diffractometer) and some parts of the instrument are not working for
    > > the moment, so i want to disable all error i get from this instrument
    > > (are coded like exceptions)

    >
    > What I usually do in comparable situations is to write STUB code for
    > the parts of the system that don't work yet.
    > Write your stub code so that it does nothing, but doesn't raise any
    > exceptions too. The only thing you then have to do is write the rest
    > of the code as you would have done, and once the Stubbed parts work,
    > replace the stub code with the real code.


    ....and if you think you want to get exceptions later:

    def fixme():
    pass


    Sprinkle fixme()s through your code, then redefine later:

    def fixme():
    raise NotImplementedError()


    John
     
    John J. Lee, May 31, 2004
    #11
  12. Calvin Spealman

    Peter Hansen Guest

    Zunbeltz Izaola wrote:

    > Peter Hansen <> writes:
    >>Zunbeltz Izaola wrote:
    >>>I want to continue executing the try block from the point the
    >>>exception was raised.

    >>
    >>Not possible except, perhaps, with a significant amount of
    >>working involving sys.settrace(). I think you need to find
    >>another way to solve the problem.

    >
    > But what I'm doing is not unittest.


    Pardon: I don't know why I thought this was related to testing
    code.

    > My program is controling and instrument (an x-ray powder
    > diffractometer) and some parts of the instrument are not working for
    > the moment, so i want to disable all error i get from this instrument
    > (are coded like exceptions)


    What is the interface to the instrument? Is there some sort of
    driver/wrapper layer that handles the communication with the
    device? Your only hope, I think, is to intercept things at
    that level and avoid/trap the exceptions before they get up
    to the higher level. In effect, stubs as Irmen suggested...

    It sounds like you are quite capable of figuring it out at
    this point, though, since all you wanted to know was whether
    you could continue after an exception and now you know you
    cannot. :)

    -Peter
     
    Peter Hansen, Jun 1, 2004
    #12
  13. According to Scott David Daniels <>:
    > Calvin Spealman wrote:
    > > ...
    > > Have to admit tho, a continue feature might be useful. Some languages have
    > > this, don't they? The thing is, Where exactly to continue? Should you retry
    > > whatever raised the exception, continue just after it, at the beginning of
    > > that line, or what?
    > >

    > See this older thread:
    > <http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>
    >
    > Xerox's experience (in deliberately removing the "continue from
    > exception" language feature) I found very instructive.


    Are the bugs mainly in the implementation of that feature, or in user
    code attempting to use said feature?

    (I notice the older thread was one year ago. Is this an annual topic? ;-)

    BTW, Common Lisp has this, called "restarts". There are about half a dozen
    Common Lisp implementations and none appear to have gotten restarts
    terribly wrong.

    Cheers.


    --
    Ng Pheng Siong <>

    http://firewall.rulemaker.net -+- Firewall Change Management & Version Control
    http://sandbox.rulemaker.net/ngps -+- ZServerSSL/Zope Windows Installers
     
    Ng Pheng Siong, Jun 1, 2004
    #13
  14. Calvin Spealman

    Jeff Epler Guest

    > According to Scott David Daniels <>:
    > > See this older thread:
    > > <http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>


    On Tue, Jun 01, 2004 at 12:59:29AM +0000, Ng Pheng Siong wrote:
    > (I notice the older thread was one year ago. Is this an annual topic? ;-)


    Perhaps the older thread had an exception, but now it's been re-started?

    Jeff

    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.4 (GNU/Linux)

    iD8DBQFAu/DWJd01MZaTXX0RAjtjAJ9U2x7VZ4Et2LwlH7B4mFK7gXQyEwCeKwlA
    l1ze/lr+g0ena9p+Sq87e9I=
    =PqxJ
    -----END PGP SIGNATURE-----
     
    Jeff Epler, Jun 1, 2004
    #14
  15. Peter Hansen <> writes:


    > Pardon: I don't know why I thought this was related to testing
    > code.


    No problem :)

    >
    > > My program is controling and instrument (an x-ray powder
    > > diffractometer) and some parts of the instrument are not working for
    > > the moment, so i want to disable all error i get from this instrument
    > > (are coded like exceptions)

    >
    > What is the interface to the instrument? Is there some sort of
    > driver/wrapper layer that handles the communication with the
    > device? Your only hope, I think, is to intercept things at
    > that level and avoid/trap the exceptions before they get up
    > to the higher level. In effect, stubs as Irmen suggested...
    >


    Finally I do something similar to Irmen's suggestion.

    > It sounds like you are quite capable of figuring it out at
    > this point, though, since all you wanted to know was whether
    > you could continue after an exception and now you know you
    > cannot. :)
    >


    Yes, I only wanted to know if there was an easy way to continue after
    an exception; and I can't (nobody can :)

    Thanks to all for your answers (and sorry for re-starting and annual
    thread)

    Zunbeltz

    > -Peter


    --
    Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
    dotes
    Materia Kondentsatuaren Fisika Saila |
    Zientzia eta Teknologia Fakultatea | Phone: 34946015326
    Euskal Herriko Unibertsitatea |
    PK 644 | Fax: 34 944648500
    48080 Bilbo (SPAIN) |
     
    Zunbeltz Izaola, Jun 1, 2004
    #15
  16. Scott David Daniels <> writes:

    > Calvin Spealman wrote:
    > > ...
    > > Have to admit tho, a continue feature might be useful. Some languages have
    > > this, don't they? The thing is, Where exactly to continue? Should you retry
    > > whatever raised the exception, continue just after it, at the beginning of
    > > that line, or what?
    > >

    >
    > See this older thread:
    > <http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>
    >
    > Xerox's experience (in deliberately removing the "continue from
    > exception" language feature) I found very instructive.


    Funny, Common Lisp (and some of its ancestors) allows you to "fiddle
    things and and return as well as even return from the exception", and
    people who write industrial strength applications is Common Lisp
    repeatedly state that this feature allows them to write software which
    is much more robust than any they would otherwise be able to
    create. Some go as far as considering any language without this
    feature to be fundamentally flawed. I have never heard anyone identify
    this feature as a source of bugs.

    So I am tempted to conclude that the Mesa implementation was flawed
    .... or maybe it was just the users who were flawed. The concept itself
    seems to have proven its worth over time.
     
    Jacek Generowicz, Jun 1, 2004
    #16
  17. Scott David Daniels <> writes:

    > Calvin Spealman wrote:
    >> ...
    >> Have to admit tho, a continue feature might be useful. Some languages have
    >> this, don't they? The thing is, Where exactly to continue? Should you retry
    >> whatever raised the exception, continue just after it, at the beginning of
    >> that line, or what?
    >>

    > See this older thread:
    > <http://groups.google.com/groups?threadm=3edd6118%241%40nntp0.pdx.net>
    >
    > Xerox's experience (in deliberately removing the "continue from
    > exception" language feature) I found very instructive.


    Did this language support working interactively? If so I'd be pretty surprised
    to hear that no one found it useful to be able to manually fix things and
    continue execution; not being able to do so is presumably my number one gripe
    with python [1] -- it annoys me no end if I need to start an expensive
    computation from scratch because some trivial and easily fixable problem
    occured towards the end of the computation (sometimes it is possible to
    salvage stuff by hand by pickling things from the appropriate post-mortem
    frame, but I'd *much* prefer being able to say: foo=some_value; resume).

    'as


    Footnotes:
    [1] Number 2 would be the stupid try: finally: idiom which also seems to
    screw up tracebacks (which has occasionally led me to get rid of them
    completely while debugging -- surely not a good thinge). My other gripes
    are again related to python's limitations for interactive software
    development -- I rather like python, but I really wish it did that better.
     
    Alexander Schmolck, Jun 1, 2004
    #17
  18. Calvin Spealman

    Larry Bates Guest

    I'm going to jump in here and make an observation.
    It sounds like you have too much code in a single
    try/except block. If you have independent calls
    to instrument interface put each of them that might
    fail in a separate try/except block. I've needed
    to do this in an earlier project and I log errors
    in a log file for review.

    Something like:

    try: data=getsomedatafrominstrumentfunc1()
    except:
    logf.writelines("W","Unable to communicate with func1")

    try: data=getsomedatafrominstrumentfunc2()
    except:
    logf.writelines("W","Unable to communicate with func2")

    My understanding is that try/except overhead is very low
    (especially if there is not an exception).

    HTH,
    Larry Bates
    Syscon, Inc.

    "Zunbeltz Izaola" <> wrote in message
    news:...
    > Peter Hansen <> writes:
    >
    >
    > > Pardon: I don't know why I thought this was related to testing
    > > code.

    >
    > No problem :)
    >
    > >
    > > > My program is controling and instrument (an x-ray powder
    > > > diffractometer) and some parts of the instrument are not working for
    > > > the moment, so i want to disable all error i get from this instrument
    > > > (are coded like exceptions)

    > >
    > > What is the interface to the instrument? Is there some sort of
    > > driver/wrapper layer that handles the communication with the
    > > device? Your only hope, I think, is to intercept things at
    > > that level and avoid/trap the exceptions before they get up
    > > to the higher level. In effect, stubs as Irmen suggested...
    > >

    >
    > Finally I do something similar to Irmen's suggestion.
    >
    > > It sounds like you are quite capable of figuring it out at
    > > this point, though, since all you wanted to know was whether
    > > you could continue after an exception and now you know you
    > > cannot. :)
    > >

    >
    > Yes, I only wanted to know if there was an easy way to continue after
    > an exception; and I can't (nobody can :)
    >
    > Thanks to all for your answers (and sorry for re-starting and annual
    > thread)
    >
    > Zunbeltz
    >
    > > -Peter

    >
    > --
    > Zunbeltz Izaola Azkona | wmbizazz at lg dot ehu
    > dotes
    > Materia Kondentsatuaren Fisika Saila |
    > Zientzia eta Teknologia Fakultatea | Phone: 34946015326
    > Euskal Herriko Unibertsitatea |
    > PK 644 | Fax: 34 944648500
    > 48080 Bilbo (SPAIN) |
     
    Larry Bates, Jun 1, 2004
    #18
  19. Calvin Spealman

    John J. Lee Guest

    Peter Hansen <> writes:
    > Zunbeltz Izaola wrote:

    [...]
    > > But what I'm doing is not unittest.

    >
    > Pardon: I don't know why I thought this was related to testing
    > code.

    [...]

    It couldn't be that you're obsessed with unit testing, of course
    <wink>.


    John
     
    John J. Lee, Jun 1, 2004
    #19
  20. Calvin Spealman

    Hung Jung Lu Guest

    Alexander Schmolck <> wrote:
    > Did this language support working interactively? If so I'd be pretty surprised
    > to hear that no one found it useful to be able to manually fix things and
    > continue execution; not being able to do so is presumably my number one gripe
    > with python [1] -- it annoys me no end if I need to start an expensive
    > computation from scratch because some trivial and easily fixable problem
    > occured towards the end of the computation (sometimes it is possible to
    > salvage stuff by hand by pickling things from the appropriate post-mortem
    > frame, but I'd *much* prefer being able to say: foo=some_value; resume).


    The edit-and-continue feature is also standard in the Microsoft world.
    Visual C++ and Visual Basic 6.0 all have this feature. (VB.NET does
    not, but they are implementing it for the version 2005 aka Visual
    Studio Whidbey.) Edit-and-continue is useful debugging tool,
    especially if the initial-state setup is expensive.

    Python is good, but not good enough in many areas.

    > Footnotes:
    > [1] Number 2 would be the stupid try: finally: idiom which also seems to
    > screw up tracebacks (which has occasionally led me to get rid of them
    > completely while debugging -- surely not a good thinge). My other gripes
    > are again related to python's limitations for interactive software
    > development -- I rather like python, but I really wish it did that
    > better.


    There are a few lessons learnt from younger programming languages,
    like Io. One lesson is that you really would like to avoid rigid
    statement syntax. In the example of the original topic of this thread,
    you cannot intercept/override exception handling mechanism because the
    try:...except:... block is not a function. Similar situations happen
    with issues regarding aspect-oriented programming. In a language like
    Io, everything is a method that send message to an object. Even
    If(...) statements are methods, as well as loops. The advantage is you
    can intercept things at your heart's content. In comparison, Python's
    exception handling is not interceptible, because exception handling is
    hard-coded in syntax.

    It does not mean all hope is lost in Python. But it does mean that
    instead of using the raise... statement in Python, you need to call a
    function/method instead. You can then intercept at that level: either
    by actually throwing an exception, or by redirecting it to some user
    intervention funtion, or by totally ignoring it (like using a 'pass'
    statement.)

    Interactive programming with features like edit-and-continue still has
    room to grow (most edit-and-continue features are not transactional,
    that is, you cannot revert changes easily.) But in my opinion that's
    an arena for prototype-based languages, and down the line, for
    reversible-computing languages. Frankly, theoretically it is possible
    to have a development environment where you never need to restart your
    program (for non-real-time applications.)

    As for Python's interactive programming, I've done some experiment
    before. It's not totally impossible. It's a bit uncomfortable. Python
    does have module reload and weakref. When you use these tools
    properly, you can achieve a high degree of non-stop programming. It
    does not come as part of the language per-se. You need to build up
    some tools yourself first. But after that, you can achieve non-stop
    programming, more-or-less. After all, Zope is a living example of a
    Python application where you can program a lot of things, without
    shutting down the server.

    regards,

    Hung Jung
     
    Hung Jung Lu, Jun 1, 2004
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Herr Lucifer
    Replies:
    0
    Views:
    574
    Herr Lucifer
    Jun 21, 2004
  2. Ahmed Moustafa
    Replies:
    5
    Views:
    30,102
    Chris Smith
    Jul 14, 2004
  3. Paul Miller
    Replies:
    3
    Views:
    1,050
    Alex Martelli
    Nov 12, 2003
  4. Replies:
    3
    Views:
    631
    Sherm Pendley
    Apr 16, 2007
  5. Lie
    Replies:
    3
    Views:
    699
Loading...

Share This Page