Re: exception handling in complex Python programs

Discussion in 'Python' started by Maric Michaud, Aug 22, 2008.

  1. Le Thursday 21 August 2008 09:34:47 Bruno Desthuilliers, vous avez écrit :
    > > The point
    > > is that EAFP conflicts with the interest of reporting errors as soon
    > > as possible (on which much has been written see, for instance Ch. 8 -
    > > Defensive Programming in Code Complete),

    >
    > Defensive programming makes sense in the context of a low-level language
    >    like C where errors can lead to dramatic results. In high-level
    > languages like Python, the worse thing that an unhandled exception can
    > cause is an abrupt termination of the process and a nice traceback on
    > screen.


    ... and leave your datas in inconsistent state. So, what C or any other
    language could do worse to your application ?

    > In this context, defensive programming is mostly a waste of time
    > - if you can't *correctly* handle the exception where it happens, then
    > doing nothing is the better solution.


    If I don't buy the argument I actually agree with the conclusion. Each
    component of a program should try to manage only errors tied to their own
    logic and let pass others up to the gui logic for rendering errors the good
    way, persistence logic to rollback unwanted changes, and application logic to
    continue execution the right way. This is hard to do in C because you have no
    way to trap an error which happen randomly in the program, ie. a segfault
    will interrupt the execution anyway.

    --
    _____________

    Maric Michaud
    Maric Michaud, Aug 22, 2008
    #1
    1. Advertising

  2. Maric Michaud a écrit :
    > Le Thursday 21 August 2008 09:34:47 Bruno Desthuilliers, vous avez écrit :
    >>> The point
    >>> is that EAFP conflicts with the interest of reporting errors as soon
    >>> as possible (on which much has been written see, for instance Ch. 8 -
    >>> Defensive Programming in Code Complete),

    >> Defensive programming makes sense in the context of a low-level language
    >> like C where errors can lead to dramatic results. In high-level
    >> languages like Python, the worse thing that an unhandled exception can
    >> cause is an abrupt termination of the process and a nice traceback on
    >> screen.

    >
    > ... and leave your datas in inconsistent state.


    Not all applications persist data, so this is an application-specific
    problem, to be solved at the application level - IOW, there's no
    one-size-fits-all solution here. Anyway: transactions management is not
    what I meant when talking about defensive programming.

    As far as I'm concerned, the only place where the defensive approach
    really makes sense whatever the language is when dealing with external
    datas (user inputs etc).

    > So, what C or any other
    > language could do worse to your application ?


    An error in a C program can do *way* worse than leave an application's
    data in inconsistent state. See ART for more on this:
    http://dialspace.dial.pipex.com/prod/dialspace/town/green/gfd34/art/

    >> In this context, defensive programming is mostly a waste of time
    >> - if you can't *correctly* handle the exception where it happens, then
    >> doing nothing is the better solution.

    >
    > If I don't buy the argument


    cf above - maybe you buy it after all ?-)

    > I actually agree with the conclusion. Each
    > component of a program should try to manage only errors tied to their own
    > logic and let pass others up to the gui logic for rendering errors the good
    > way, persistence logic to rollback unwanted changes, and application logic to
    > continue execution the right way. This is hard to do in C because you have no
    > way to trap an error which happen randomly in the program, ie. a segfault
    > will interrupt the execution anyway.


    Indeed.
    Bruno Desthuilliers, Aug 22, 2008
    #2
    1. Advertising

  3. Le Friday 22 August 2008 15:03:21 Bruno Desthuilliers, vous avez écrit :
    > Maric Michaud a écrit :
    > > Le Thursday 21 August 2008 09:34:47 Bruno Desthuilliers, vous avez écrit :
    > >>> The point
    > >>> is that EAFP conflicts with the interest of reporting errors as soon
    > >>> as possible (on which much has been written see, for instance Ch. 8 -
    > >>> Defensive Programming in Code Complete),
    > >>
    > >> Defensive programming makes sense in the context of a low-level language
    > >> like C where errors can lead to dramatic results. In high-level
    > >> languages like Python, the worse thing that an unhandled exception can
    > >> cause is an abrupt termination of the process and a nice traceback on
    > >> screen.

    > >
    > > ... and leave your datas in inconsistent state.

    >
    > Not all applications persist data, so this is an application-specific
    > problem, to be solved at the application level - IOW, there's no
    > one-size-fits-all solution here.


    ... or lose open connection, reset sessions, etc.. it doesn't really matter
    what is lost when a program crash, if it can be restarted without changes it
    is hardly what I'd qualify a "dramatic result". It doesn't depend on the
    language what implications of an unhandled error are, It is always
    application-specific.

    > Anyway: transactions management is not
    > what I meant when talking about defensive programming.
    >
    > As far as I'm concerned, the only place where the defensive approach
    > really makes sense whatever the language is when dealing with external
    > datas (user inputs etc).
    >


    I agree, this is my whole point, "whatever the language is".

    > > So, what C or any other
    > > language could do worse to your application ?

    >
    > An error in a C program can do *way* worse than leave an application's
    > data in inconsistent state. See ART for more on this:
    > http://dialspace.dial.pipex.com/prod/dialspace/town/green/gfd34/art/
    >


    I didn't read "dramatic results" in that sense, but with the meaning of a
    result that the program itself cannot handle.

    If the whole system crash due to an unhandled error in a program, once
    missile's dropped it doesn't really matter in which language it was written.
    Reliability of a system, as high-availability of an application, is mostly a
    problem beyond the scope of application level error checking.

    > >> In this context, defensive programming is mostly a waste of time
    > >> - if you can't *correctly* handle the exception where it happens, then
    > >> doing nothing is the better solution.

    > >
    > > If I don't buy the argument

    >
    > cf above - maybe you buy it after all ?-)
    >
    > > I actually agree with the conclusion. Each
    > > component of a program should try to manage only errors tied to their own
    > > logic and let pass others up to the gui logic for rendering errors the
    > > good way, persistence logic to rollback unwanted changes, and application
    > > logic to continue execution the right way. This is hard to do in C
    > > because you have no way to trap an error which happen randomly in the
    > > program, ie. a segfault will interrupt the execution anyway.

    >
    > Indeed.
    > --
    > http://mail.python.org/mailman/listinfo/python-list




    --
    _____________

    Maric Michaud
    Maric Michaud, Aug 22, 2008
    #3
    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. Replies:
    12
    Views:
    1,615
    Dave Thompson
    Jan 10, 2005
  2. Bruno Desthuilliers

    Re: exception handling in complex Python programs

    Bruno Desthuilliers, Aug 21, 2008, in forum: Python
    Replies:
    6
    Views:
    342
    magloca
    Aug 22, 2008
  3. Replies:
    1
    Views:
    340
    eliben
    Aug 22, 2008
  4. lone_eagle
    Replies:
    3
    Views:
    622
    psykeedelik
    May 26, 2009
  5. Peter
    Replies:
    34
    Views:
    1,915
    James Kanze
    Oct 17, 2009
Loading...

Share This Page