general sense of exception handlers

utzoo!decvax!ittvax!sii!mem utzoo!decvax!ittvax!sii!mem
Mon Nov 1 23:47:03 AEST 1982


c
I'd like to dispute the notion that the "on event" construct is
improper.  Thank you, thank you.  The opinion seems to be that
exception handlers are unclean, because they lead away from a
clear flow of control.  They do.  When you have an operating
system to take care of all the assorted spontaneous happenings
in and around your computer, the need for local service routines
seems to be partially obviated.  Partially.  But what is going
on around you?  Do you use co-routines?  and think of them as
clean?  Do you wait for the completion of every operating system
function, or do you use a proceed option.  For every proceed call
you issue, you're explictly declaring the knowledge of background
work (i.e., exception-level) being done.  For that matter, many
operating system calls make this declaration.

And once you start writing code which isn't destined to have that
operating system support, exception handling is pretty much
mandated.  

Look also at typical real-time multitasking systems, wherein
tasks are generally servers for particular functions, on demand.
It is handy to be able to express this demand as an asynchronous
trap, and it would be nice to have support for this in the
implentation language.

Mark Mallett



More information about the Comp.lang.c mailing list