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 didnt 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, Im faced with a detected error. The first thing to do is fold your tentthat 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. Im going to initiate the massive dumping now. When you report an error, you should classify it. You should give it a name. If youre a component that reports errors, there should be an exhaustive list of the errors that you would report. Thats one of the real problems in todays 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 Im suddenly faced with D, E, and F at my level and theres 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 thats because youre allowed to ignore errors. Ive sometimes advocated that, no, youre not allowed to ignore any error. You can reclassify an error and report it back up, but youve 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
