[plt-scheme] to define, or to let (new twist)

Bradd wrote:
>> If the program must not fail, then "soft" and "hard" failures are
>> equally unacceptable....

Paul Schlie wrote:
> - as I suspect you'd agree, unacceptable or not, they occur and must
>   be dealt with in as practical a way as possible, as dictated by the
>   application's requirement.

No, I don't agree. There are two general approaches to software that
must not fail.

1. The engineers keep the application as simple as possible, and they
   formally prove that the system cannot fail because of software
   defects. If there are non-software elements of the system that can
   fail, they design application-specific failsafes to handle those
   situations gracefully.

2. The engineers use normal software tools with few failsafes.

The second approach is disturbingly unsafe, but unfortunately it does
get used in practice. 

In either case, there is no generally-acceptable way to deal with
failures. Failsafes are major elements of the software requirements and
design, and there are no "off the shelf" solutions. Or, to put it
another way, a mission-critical or life-critical application that relies
on "off the shelf" solutions is really just an example of #2 above.

>> There is no general way to handle exceptional situations. One really
>> must consider the nature of the program and the nature of the
>> exception. Exception-handling is an important element of program
>> design, and there is no generally-useful "default" IMO.
> 
> - fully agree that many factors influence the specification and utilization
>   of exception handling within program code; however it should be clear that
>   without a facility to enable the localized capture, classification and
>   subsequent in-context resumption of scheme expressions which encounter
>   "errors"; one can't even begin to specify exception handling behaviors,
>   as may be desired, if not required for certain classes of applications.

But Scheme already has a totally-general mechanism for dealing with
exceptional behavior: continuation capture. And there already is a SRFI
that implements a less general and more usable exception-handling
mechanism.
-- 
Bradd W. Szonye
http://www.szonye.com/bradd