[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
ttp://se-server.ethz.ch/RAMSES/Objects/DM/DMSystem.html#DMSystem
explaining such stack management of program modules.
More on this topic also in Wirth et al., 1992 (http://www.sysecol.ethz.ch/RAMSES/MacMETH.html#Wirth92
).
Regards,
Andreas
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
SWITZERLAND
address@hidden
www.sysecol.ethz.ch
+41 44 633-6090 phone
+41 44 633-1136 fax
Make it as simple as possible, but distrust it!
________________________________________________________________________
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.
Thanks,
--
Martin Kalbfuß <address@hidden>
_______________________________________________
gm2 mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/gm2