Re: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
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=Contentpa=showpagepid=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 -
Re: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
| 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 All these obsolete ideas. Stack tracebacks. Feh! Years back at Smarts, a company since acquired by the EMC you see in my email address, one of the things I added to the system was a set of signal handlers which would print a stack trace. The way to do this was very non-uniform: On Solaris, you had to spawn a standalong program (but you got a stack trace of all threads). On HPUX, there was a function you could call in a system library. On AIX (you'd think IBM, of all vendors, would do better!) and Windows, we had to write this ourselves, with varying degrees of OS support. We also dump - shock! horror! - the values in all the registers. And we (try to) produce a core dump. My experience has been that of crashes in the field, 90% can be fully analyzed based on what we've written to the log file. Of the rest, some percentage - this is harder to estimate because the numbers are lower; - can be fully analyzed using the core dump. The rest basically can't be analyzed without luck and repetition. (I used to say 80-90% for can be analyzed from core file, but the number is way down now because (a) we've gotten better at getting information into and out of the log files - e.g., we now keep a circular buffer of messages, including those at too low a severity level to be written to the log, and dump that as part of the failure output); (b) the remaining problems are exactly the ones that the current techniques fail to handle - we've fixed the others!) -- Jerry ___ 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
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=Contentpa=showpagepid=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
[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
Re: [SC-L] Retrying exceptions - was 'Coding with errors in mind'
On Fri, 1 Sep 2006, Jonathan Leffler wrote: | 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. This is an over-simplification of the story. I may get some of the details wrong, but This dates back to work done at Xerox PARC in the late 70's-early 80's - about the same time that Smalltalk was being developed. There was a separate group that developed system programming languages and workstation OS's built on them. For a number of years, they worked on and with a language named Mesa. Mesa had extensive support for exceptions, including a resumption semantics. If you think of exceptions as a kind of software analogue to a hardware interrupt, then you can see why you'd expect to need resumption. And, indeed, the OS that they built initially used resumption in a number of places. What was observed by the guys working on the system was that the number of uses of resumption was declining over time. In fact, I vaguely remember that when they decided to go and look, they were using resumption in exactly two places in their entire code base - OS, compilers, windowing system, various tools. (Exceptions were used extensively - but resumption hardly at all.) It's not that anyone deliberately set out to remove uses of resumption. Rather, as the code was maintained, it repeatedly turned out that resumption was simply the wrong semantics. It just did not lead to reliable code; there were better, more understandable, more robust ways to do things that, over time and without plan, came to dominate. Somewhere, I still have - if I could ever find it in my garage - the paper that described this. (It was a retrospective on the effort, almost certainly published as one of the PARC tech reports.) Mesa was replaced by Cedar, which was a simpler language. (Another lesson was that many of the very complex coercion and automatic conversion mechanisms that Mesa weren't needed.) I think Cedar discarded Mesa's exception resumption semantics. Many of the people involved in these projects later moved to DEC SRC, where they used the ideas from Mesa and Cedar in Modula2+ and later Modula3 - a dramatically simpler language than its older Xerox forbearers. It also used exceptions heavily - but never had resumption semantics. Much of the basic design of Java and C# goes back to Modula3. | How much are retryable exceptions really used, in | Ruby or anywhere else that supports them? Not only how much are they used, but how well do they work? Remember, if you'd look at *early* instances of Mesa code, you might well have concluded that they were an important idea. It may well be that for quick one-off solutions, resumption is handy - e.g., for building advise-like mechanisms to add special cases to existing code. But as we should all know by now, what works in-the-small and in-the-quick is not necessarily what works when you need security/reliability/ maintainability/supportability. -- Jerry ___ 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
