🚀 go-pugleaf

Simon Egli (eglis@ubaclu.unibas.ch) wrote:
: In article <4b3trk$3g7@sifon.cc.mcgill.ca>, whitney@christie.Meakins.McGill.CA (Whitney de Vries) writes:
: > Eric W. Nikitin (enikitin@junior.wariat.org) wrote:
: > : Whitney de Vries (whitney@christie.Meakins.McGill.CA) wrote:
: > : : Modula-3's static based exception handling mechanism is insufficient
: > : : for supporting the extensible programming style used in Oberon.
: > : : The basic gist is that extensions may include "exception" conditions
: > : : that are unforseen by the programmer of the base/carrier.
: > 
: > : : Syzperski's thesis on ETHOS has a nice explaination of this.
: > 
: > : Ok... what would you suggest instead?
: > 
: > Syzperski's describes a technique that allows a system programmer
: > to introduce a stack of exception handlers into a system. They are
: > designed as guards for up-calls. Up-calls that fail cause only the
: > upper most level to fail whereas in the classic Oberon system 
: > programmer errors can cause the entire system to fail.

: So theoretically it should be possible to guarantee that no application can
: cause the whole system to fail.

Yes. This is the intention of the above mechanism. Without
a "program" failure has the potential of invalidating the
entire system. With it the system can be unrolled to the
last safe level. In contrast to unix where the objective
of the kernel is protect itself ( killing off errant programs/processes
when necessary ), the orginal Oberon system does not define
such a base. The system can be freely extended and the extensions
are free to work with all parts of the system with the potential
of invalidating the whole system. The above technique 
allows failed portions of a system can be removed without 
having to resort the concept of a program/process. Yet it still 
permits Oberon style extensibility.

Again - this is a system program technique. It is not a language
feature.

-- Whitney