As pointed out in
http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&th=fb2df1fd31bc3bc9&seekm=2plvhf%24o01%40src-news.pa.dec.com&frame=off
range violations are errors that cannot be catched. By the way can they be
disabled for efficiency reasons? At least in UNSAFE modules? Maybe with
PRAGMAs for enabling and disabling the checks, as well as restoring the
previous check states (nested enabling/disabling).
In many applications the user is allowed to input numbers and it is
pretty hard to predict if the computation may cause an overflow or not.
E.g. the user is requested to type in a block number and a block size and
we want to get the total size, that is the product of block number and
block size. The limitting quantity is the range of a CARDINAL, but to
assert a successful multiplication one either has to limit as well "block
size" and "block number" or one has to do complicated tests of the result
validity. The first alternative restricts the users freedom too much. The
second one is unnecessary inefficient because every CPU set flags when an
operation fails, but only the Modula3 run time can read them and turns
them immediately into exceptions that can not be catched.
One solution is suggested by Warren D. Smith in the WordEx module of the
m3na library: One could extend the Word module by routines that allow
access to the Carry and Overflow bits. They are provided as Modula-3
routines which simulate the effect of the machine commands but they should
be better substituted by the compiler by real machine commands.
Then the programmer can react on Carry bits e.g. by throwing a custom
(catchable) exception.
The next question is how to handle overflows in the m3na library? Should
its routines raise (uncatchable) builtin exceptions (this is the current
state and does not need any special support) or should they raise
catchable (custom) exceptions? Because m3na routines are mostly applied
to user data, that are data which can be hardly predicted I prefer the
second alternative. The consequence is that nearly every m3na routine may
throw an exception. (This is nothing bad, though.)
