Retrying exceptions - was 'Coding with errors in mind'

[mshines at purdue.edu (Michael S Hines)]

Oh, you mean like the calling conventions on the IBM Mainframe where a dump
produces a trace back up the call chain to the calling program(s)?  Not to
mention the trace stack kept within the OS itself for problem solving
(including system calls or SVC's as we call them on the mainframe).   And
when all else fails, there is the stand alone dump program to dump the whole
system?

Mainframes have been around for years.  It's interesting to see "open
systems" take on mainframe characteristics after all this time....

Mike Hines
Mainframe Systems Programmer

-----Original Message-----
From: Gunnar Peterson [mailto:gunnar at arctecgroup.net]
Sent: Tuesday, September 05, 2006 5:29 PM
To: Hines, Michael S.
Cc: sc-l at securecoding.org
Subject: Re: [SC-L] Retrying exceptions - was 'Coding with errors in mind'

I can't say enough good things about this interview:

Conversation with Bruce Lindsay
Design For Failure
http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=233

<snip>
BL: There are two classes of detection. One is that I looked at my own guts
and they didn't look right, and so I say this is an error situation. The
other is I called some other component that failed to perform as requested.
In either case, I'm faced with a detected error. The first thing to do is
fold your tent-that is, put the state back so that the state that you manage
is coherent. Then you report to the guy who called you, possibly making some
dumps along the way, or you can attempt alternate logic to circumvent the
exception.

In our database projects, what typically happens is it gets reported up, up,
up the chain until you get to some very high level that then says, "Oh, I
see this as one of those really bad ones. I'm going to initiate the massive
dumping now."
When you report an error, you should classify it. You should give it a name.
If you're a component that reports errors, there should be an exhaustive
list of the errors that you would report.

That's one of the real problems in today's programming language architecture
for exception handling. Each component should list the exceptions that were
raised:
typically if I call you and you say that you can raise A, B, and C, but you
can call Joe who can raise D, E, and F, and you ignore D, E, and F, then I'm
suddenly faced with D, E, and F at my level and there's nothing in your
interface that said D, E, and F errors were things you caused. That seems to
be ubiquitous in the programming and the language facilities. You are never
required to say these are all the errors that might escape from a call to
me.
And that's because you're allowed to ignore errors. I've sometimes advocated
that, no, you're not allowed to ignore any error. You can reclassify an
error and report it back up, but you've got to get it in the loop.
</snip>

-gp


Quoting Michael S Hines <mshines at purdue.edu>:

> That's a rather pragmatic view, isn't it?
>
> Perhaps if other language constructs are not used, they should be removed?
>
> OTOH - perhaps the fault is not the language but the coder of the
language?
>   - lack of knowledge
>   - pressure to complete lines of code
>   - lack of [management] focus on security
>   - or 100s of other reasons not to do the right thing...
>
> Sort of like life, isn't it?
>
> Mike Hines
>
> -----Original Message-----
> From: sc-l-bounces at securecoding.org
> [mailto:sc-l-bounces at securecoding.org]
> On Behalf Of Jonathan Leffler
> Sent: Friday, September 01, 2006 3:44 PM
> To: sc-l at securecoding.org
> Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
>
> Pascal Meunier <pmeunier at cerias.net> wrote:
> > Tim Hollebeek <tholleb at teknowledge.com> wrote:
> > > (2) in many languages, you can't retry or resume the faulting code.
> > >     Exceptions are really far less useful in this case.
> >
> > See above.  (Yes, Ruby supports retrying).
>
> Bjorn Stroustrup discusses retrying exceptions in "Design and
> Evolution of
> C++" (http://www.research.att.com/~bs/dne.html).  In particular, he
> described one system where the language supported exceptions, and
> after some number of years, a code review found that there was only
> one retryable exception left - and IIRC the code review decided they
> were better off without it.  How much are retryable exceptions really
> used, in Ruby or anywhere else that supports them?
>
> --
> Jonathan Leffler (jleffler at us.ibm.com) STSM, Informix Database
> Engineering, IBM Information Management Division 4100 Bohannon Drive,
> Menlo Park, CA 94025-1013
> Tel: +1 650-926-6921     Tie-Line: 630-6921
>           "I don't suffer from insanity; I enjoy every minute of it!"
>
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at -
> http://www.securecoding.org/list/charter.php
>
>
> _______________________________________________
> Secure Coding mailing list (SC-L)
> SC-L at securecoding.org
> List information, subscriptions, etc -
> http://krvw.com/mailman/listinfo/sc-l
> List charter available at - http://www.securecoding.org/list/charter.php