At 02:19 AM 1/19/2007, Sean Conner wrote:
My question is about the condition handler. In the
text, it's
described
as:
A longword condition handler address. Here, the calling routine
may store the address of an error-handling routine to be
called if
an exceptional error condition arises in the procedure.
This is the only section (as far as I can tell) where this is
described,
and I'm curious as to how exactly it worked. It appears that while
the CPU
may set this location to 0, its purpose isn't really dictated by the
hardware, but it a convention used by VMS. But then (as I was typing
this),
I was struct by this bit:
... the calling routine may store ...
Huh? How?
The calling routine can store a condition handler in *it's own* stack
frame prior to a call. Any exceptions that occur in the called routine
are first handled by the called routine's condition handler (if there
is one) and are then passed down if necessary to the caller's condition
handler.
The caller can not set the called routine's condition handler (by
convention that would be wrong as it breaks the nesting (handlers
called top-to-bottom). More importantly, the CALL* instruction would
overwrite the stack location that contains the called routine's handler
with a zero.
How this is very frequently used in VMS code is for message printing;
you enable a condition handler in the main function that decodes the
arguments and prints a message. Upper layers just signal() a condition
and let the lower layers decide what to do with it, with the default
being the main function's message printer. An intermediate function
that expects a possible exception can enable their own handler to
suppress errors that they're expecting.
-Rick