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:[EMAIL PROTECTED] Sent: Tuesday, September 05, 2006 5:29 PM To: Hines, Michael S. Cc: sc-l@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 <[EMAIL PROTECTED]>: > 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: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > On Behalf Of Jonathan Leffler > Sent: Friday, September 01, 2006 3:44 PM > To: sc-l@securecoding.org > Subject: [SC-L] Retrying exceptions - was 'Coding with errors in mind' > > Pascal Meunier <[EMAIL PROTECTED]> wrote: > >Tim Hollebeek <[EMAIL PROTECTED]> 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 ([EMAIL PROTECTED]) 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@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@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@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
