Re: [SC-L] Coding with errors in mind - a solution?
[Picking out one minor point:] | [Exceptions] can simplify the code because | -as previously mentioned by Tim, they separate error handling from normal | logic, so the code is easier to read (it is simpler from a human reader's | perspective). I have found bugs in my own code by going from error handling | to exceptions -- it made the mistake plain to see. I agree with this ... but: - Many years ago, I worked in a language called BASIC PLUS. (This was an extension to BASIC that DEC bought along with the RSTS operating system. It was actually a surprisingly productive environment. But the details aren't really relevant here.) BASIC PLUS had a simple exception handling approach: You specified ON ERROR statement, which requested that if any system-detected error occurred (and, in modern terms, BASIC PLUS was a safe language, so *all* errors were detected by the run-time system) then the given statement was to be executed. Almost universally, statement was a GOTO to a particular line number. At that line, you had access to the particular error that occurred (and error number); the line number on which it occurred; the current state of any variables; and the ability to resume execution (with some funny limitations). This provided exactly the separation of normal code flow from error handling that seems like a fine idea ... until you try to do anything with it other than logging the error and aborting at some high level of abstraction. I wrote an incredibly hacky error handler and a function called FNSET() that was used essentially as follows: IF (FNSET(errs)) THENnormal code ELSEerror path errs encoded the error numbers that would be handled by error path; any errors not on the list took the usual log-and-abort route. So ... this was essentially a try/catch block (which I don't think I'd seen - this was in 1976 or thereabouts), with the odd filip that you declared the error conditions you handled in the try rather than in the catch. It worked very well, and supplanted the old monolithic error handlers that preceded it. But notice that it moved the error handlers right up close to the normal operational code. Yes, it's not as close as a test after every call - *some* degree of separation is good. Really, what I think matters is that the error handling code live at the right semantic level relative to the code that it's covering. It's fine for the try/catch to be three levels of call up from where the throw occurs *if it the semantics it reflects are those of the code explicitly in its try block, not the semantics three levels down*. This is also what goes wrong with a try block containing 5 calls, whose catch block is then stuck with figuring out how far into the block we got in order to understand how to unwind properly. *Those 5 calls together* form the semantic unit being protected, and the catch should be written at that level. If it can't be, the organization of the code needs to be re-thought. (Notice that in this case you can end up with a try/catch per function call. That's a bad result: Returning a status value and testing it would probably be more readable than all those individual try/catches!) - On a much broader level: Consider the traditional place where exceptions and errors occur - on an assembly line, where the process has bugs, which are detected by QA inspections (software analogue: Assertions) which then lead to rework (exception handling). In the manufacturing world, the lesson of the past 50 years or so is that *this approach is fundamentally flawed*. You shouldn't allow failures and then catch them later; you should work to make failures impossible. Too much of our software effort is directed at better expression (try/catch) and implementation (safe languages, assertions, contract checking) of the assume it will fail, send it back for rework approach. Much, much better is to aim for
Re: [SC-L] Coding with errors in mind - a solution?
-Original Message-
From: Pascal Meunier [mailto:[EMAIL PROTECTED]
Sent: Friday, September 01, 2006 7:41 AM
To: [EMAIL PROTECTED]
Cc: Tim Hollebeek; sc-l@securecoding.org
Subject: Re: [SC-L] Coding with errors in mind - a solution?
On 8/31/06 8:05 PM, mikeiscool [EMAIL PROTECTED] wrote:
His point, I think, is that if you wrap a series of
statements in an
try/catch block, you might not roll back every statement you needed
to, or checked appropriate conditions.
For example:
try {
openFile();
getData();
writeToFile();
setSomeFlag()
moveFile();
deleteTempThings();
} catch(Exception e){
...
}
[...]
Ah, yes, I can see a bad (or under pressure) programmer
lumping together the handling of exceptions that should be
handled separately, or making just one giant try block so
when there's an exception, even if you specify the type
there's still ambiguity as to where it came from and
therefore can't handle it properly. That could be quite a
mess. Thanks.
Exceptions simplify the code? I don't think so. They also
don't reduce
code duplication [per se] you need to add extra functions,
etc, to do
that.
They can simplify the code because
-as previously mentioned by Tim, they separate error handling
from normal logic, so the code is easier to read (it is
simpler from a human reader's perspective).
But they only really separate the error handling if you have
one big try block, and that can make proper diagnosis difficult.
For example, in the above case, if you get a FileNotFound exception,
did it come from openFile or moveFile? It may be possible to
figure that out, but the extra logic will be more than you would
have had if you had just checked the return value of the call.
-if an exception is handled several call layers above, you
don't have to copy/translate and relay the error at each
layer, with the attached loss of context and possible
translation mistakes (error #3 in one layer/module may mean
something different in another...). So, there's less
(duplicated) code.
But the intervening stack frames have to be (painfully) aware of
the fact that they might terminate abruptly. Experience has shown
that getting this right is very hard, offsetting the benefits of
being able to quickly pop back up to a frame where the error can
be handled.
-It is common (and bad, IMO) practice for errors to be
signified to callers by returning an out of range or
different type (or null) value when something else is
semantically expected.
This is especially true when there is only one value available
for all errors (like zero). GetLastError/errno is a silly
substitute for not having another 'out' parameter, justified
on the basis that sometimes you don't care what the error was.
Except that you should!
Exceptions can be useful, but they really aren't what you want for
error handling, and are often cause as many problems as they cause.
What you really want is for all the (partial) side effects of a
function to disappear when it unrolls, but that's hard to do.
Even cleanup code is tough to get right due to the fact that
(A)(B)(A^-1) != B
(can we reboot the universe with that feature disabled?
It causes problems all over the place ...)
That said, Windows Vista will have transactions for file system/
registry modifications, so perhaps that will make life a bit easier...
-Tim
___
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] Coding with errors in mind - a solution?
if an exception is handled several call layers above, you don't have to copy/translate and relay the error at each layer, [...] But the intervening stack frames have to be (painfully) aware of the fact that they might terminate abruptly. That's what unwind-protect is for. What, you don't have unwind-protect? Perhaps you need to fix that first. :-) Actually, I have found it not all that difficult. I have (ab?)used gcc's nested-function nonlocal-goto support as an error-handling throw facility relatively often, and I've run into very few cases where intervening stack frames have to be aware of the throw-through-them potential, and none where I would say it was painful. Perhaps that's just an artifact of how I design my code /~\ The ASCII der Mouse \ / Ribbon Campaign X Against HTML [EMAIL PROTECTED] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B ___ 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
