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

[Fischlin Andreas]

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