[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gm2] cath exceptions raised in another module's init section

From: Fischlin Andreas
Subject: Re: [Gm2] cath exceptions raised in another module's init section
Date: Wed, 6 Jan 2010 15:07:50 +0100

Dear Martin,

Whoops, please be careful. I do not know the ISO definition, but Wirth's philosophy of Modula-2 would require the exception first being caught or at least giving notification within the module where it occurs. Anything else comes very contrary to the very nature of modules and recursive descendent philosophy of Modula-2.

There was also an entire thesis written on a related subject (Knudsen). The Modula-2 linking loader knows a stack of programs. Each level being a program module that is activated on top of the other. Any module referenced by several levels is used in a shared manner. If an exception occurs, each module is notified and can deal with the exception, e.g. do garbage collection. If a level is to be terminated, i.e. aborted, all termination handlers are called and only then is the top level unloaded. Any library module still in use by a lower level is kept in memory and next lower level program is resumed according to the stack structure. Of course this runs somewhat contrary to exceptions, that are in such an implementation not needed to be propagated into the source code at all. IMHO preferable over exception handling, but that's beside the point. The only thing needed is a simple declaration of initialization and termination procedures for every module that are called in case of exceptions by Modula-2's run time system.

I would hate if gm2 would get too much in the way of such philosophies or we would never be able to port all our vast code to gm2. Every module involved in an exception needs to have a chance to get notified and to be able to trigger some action, typically releasing memory. BTW, which is different from garbage collection, since this is in case of Modula-2 not yet garbage!

Consult this module for seeing such a philosophy in practice: DEF's: h
explaining such stack management of program modules.

More on this topic also in Wirth et al., 1992 ( ).


Cited References:
Knudsen, S.E., 1983. Medos-2: A Modula-2 oriented operating system for the personal computer Lilith. Diss. ETH No. 7346, Swiss Federal Institute of Technology: Zürich, Switzerland, 148 pp.

Wirth, N., Gutknecht, J., Heiz, W., Schär, H., Seiler, H., Vetterli, C. & Fischlin, A., 1992. MacMETH. A fast Modula-2 language system for the Apple Macintosh. User Manual. 4th, completely revised ed. User Manual Department of Computer Sciences (ETH), Zürich, Switzerland, 116 pp.

ETH Zurich
Prof. Dr. Andreas Fischlin
Systems Ecology - Institute of Integrative Biology
CHN E 21.1
Universitaetstrasse 16
8092 Zurich


+41 44 633-6090 phone
+41 44 633-1136 fax

             Make it as simple as possible, but distrust it!

Attachment: Fischlin Andreas.vcf
Description: Text Data

On 06/Jan/2010, at 14:49 , Martin Kalbfuß wrote:

Hi again.

I tried the following:

I raised an exception in the initialization section of an imported
module. Then I tried to catch this exception in the importing main
module. This didn't work. Is this the way it should be? When I throw an
exception in any other imported function, I can catch it in the
importing module.

I have the function InitSubSystem. It can fail. So I have to call it by
hand, to catch the exception. But the right place to put them would be
the initialization section of the SubSystem's module.


Martin Kalbfuß <address@hidden>

gm2 mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]