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

> Bradd W. Szonye wrote:
>
>> - a program comprehensively covers as desired the entire encountered
>>   (not just anticipated) range and domain of its reachable state/data space.
>> 
>>    -> no errors, no problems.
>
> Are you talking about the program as designed or the program as
> implemented? If the program never encounters an error, that's good, but
> unless you can prove that it can't possibly encounter an error, you'll
> need to plan for the following two cases.

- agreed...

>> - a program reaches an unanticipated state, due to unanticipated data,
>>   and/or erroneous program code.
>>
>>   -> data/state is still within the domain of the specified behavior
>>      of the code; no error, keeps running, although results may not be as
>>      intended.
>
> This situation is simply unacceptable in a program which must not halt.
> Not much you can say about it beyond that. If it's an embedded but
> non-critical app, you can halt, reset, and restart the system. You're
> pretty much screwed if it's a life-critical system.

- this condition was meant to depict the scenario where no errors were
  logically detected, but none-the-less were actually present, producing
  erroneous results due to logical code bugs, and/or unanticipated data
  value ranges, etc... (but not detected as an "errors", things simply keep
  going, arguably typical of most "non-catastrophic" failures resulting from
  program bugs).

  [ would be nice to avoid, but unlikely unless you know how to prove a
   program is comprehensively correct, which is likely impossible, as the
   description of the context in which a program would need to operate
   within would itself be a program subject to bugs, thus the best one could
   ever accomplish, would be to prove that two descriptions were self
   consistent; but not that either was itself actually correct. (would be
   nice but the world hasn't solved, "do what I meant, not what I said"), so
   the best one can do is try to delineate constraints on the program's
   behavior, and hope they were comprehensive enough to prevent catastrophic
   failure. ]

>>   -> data/state is outside the domain of the specified behavior of the code,
>>      error; program stops, whatever the program may have been doing (like
>>      controlling the cooling of a reactor core, it's not doing any longer,
>>      potentially catastrophic).
>
> I don't see much practical difference between these two cases, if the
> program truly must not fail. What good is it to keep the program running
> after you've detected an inconsistent program state or similar "panic"
> error? While the program may not "halt," it isn't doing what it's
> supposed to anymore, either. You can easily end up situations like the
> Airline catastrophe, where the incorrect data sets up a positive feedback
> loop.

- this condition was meant to depict the scenario where an unexpected state
  was actually detected, not by the program code, but by violation of the
  language or it's defined function's semantic specification which specified
  some condition as an error (such as divide by zero, or some code
  anticipated an byte value representing an numeric digit character being
  received from an input-stream, but actually received a alphabetic
  character value, and passed it to string->integer without checking, or
  whatever), therefore gets caught as a language run-time semantic
  violation, which isn't too difficult imagining happening, and that there
  are likely situations in which it would be preferable to not halt the
  program, (such as possibly if program had already accumulated a great
  amount of critical state history and/or context which may not be easily or
  quickly recoverable, and critical to subsequent processing requirements),
  therefore significantly more desirable to try to constrain the error to as
  fine a granularity context as possible, whether it be a subsystem, module,
  or single function, and return a known (safer than failure) result in it's
  place, thereby enabling the system to resume its execution in as close as
  possible context to the point in which the "error" was initially detected.

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

- 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.

>> So maybe it would be more generally correct to observe that a
>> recoverable exception architecture possibly similar to MzScheme's
>> should considered for R6RS ....

> 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.

-paul-