Secure Coding mailing list archives
Retrying exceptions - was 'Coding with errors in mind'
From: gunnar at arctecgroup.net (Gunnar Peterson)
Date: Tue, 5 Sep 2006 16:29:06 -0500
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
Current thread:
- Retrying exceptions - was 'Coding with errors in mind' Jonathan Leffler (Sep 01)
- Retrying exceptions - was 'Coding with errors in mind' Leichter, Jerry (Sep 01)
- Retrying exceptions - was 'Coding with errors in mind' Michael S Hines (Sep 05)
- Retrying exceptions - was 'Coding with errors in mind' Gunnar Peterson (Sep 05)
- Retrying exceptions - was 'Coding with errors in mind' Michael S Hines (Sep 06)
- Retrying exceptions - was 'Coding with errors in mind' Leichter, Jerry (Sep 06)
- Retrying exceptions - was 'Coding with errors in mind' Gunnar Peterson (Sep 05)