On Wed, 05 Jul 2000, Rob Browning wrote:
> Handling error conditions is a PITA if you want to write in a more
> functional style. One way to handle it is to make it so that #f as a
> return value is always an error, and if there's a real value, then you
> return something like (cons #t value). This, of course, makes things
> less elegant because you have to store the result before testing it.
> I.e. you have to say:
>
> (let ((result (foo)))
> (if result
> (do-something (cadr result))))
>
> but this does work around the #f "shadowing problem". With this
> approach, #f only means error. Also, once we have a functioning
> version of the and-let srfi, much of this gets easier. You can write
> an "and" that stores the value:
>
> (and-let ((result (foo)) (do-something (cadr result))))
>
> and do-something will be called iff (foo) returns a non #f value, and
> result will be bound to that value. I think this is a really helpful
> addition to the language.
I agree that error handling is a PITA in functional languages.
Unfortunately, your proposal only works one level deep.
One of the real advantages of "functional" languages is that you nest calls.
(let ((x (f1 (f2 (f3 foo)) (f4 bar)))))
Now, since f3 might return an error, you either have to manually "compile" a
string of 'and-let's
NB: Switching languages because a procedural language better illustrates the
process.
x = f1(f2(f3(foo)),f4(bar));
becomes
temp3 = f3(foo);
temp2 = f2(temp2);
temp4 = f4(bar);
temp1 = f1(temp2,temp4);
x = temp1;
Now, there are three approaches to handling the errors.
1) The language compiler can handle exceptions.
2) The caller can handle exceptions by placing a test BETWEEN each of the
function calls. (This is what 'and-let' does)
3) Each function return a {status, result}-tuple and check each of its
arguments for an error status
f1(a1,a2)
begin
if (!valid(a1)) return a1
elseif (!valid(a2)) return a2
elseif (*BadThing*) return {ERROR, BadThing}
else return {VALID, answer}
end
Each approach has its problems.
Primarily.
1) The language of choice may not handle the problem.
2) Nested function calls become unreadable
3) There is a danger that a programmer will forget the properly implement all
arguments in -tuple format and properly revert to non-tuples for calls to
sections written to a different convention.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
