rdt155r@monu6.cc.monash.edu.au (mr r vanschyndel) (09/21/90)
Hi there!
I just read the discussions in this group and thought I'd add my two cents
worth. It relates to the C compiler's response to various types of errors
and an error handling mechanism at runtime.
One of the most common errors made (by me especially), is to have one too many
open braces in some function definition, resulting in spurious error messages
through the rest of the module. This is especially frustrating to novice C
programmers, confused by the compilers erratic behaviour. I'm sure tthere are
many more tales of horror along this line.
Problems like this occur because of the context-sensitivity of parts of the
language. The compiler can get completely out of synch in certain cases,
resulting in cryptic, uncomprehensible and irrelevant error messages.
While some of this behaviour is undoubtedly implementation-dependent (Turbo-C's
error messages are much more useful than Microsoft's), some is a result of the
language definition (such as the brace business above).
A simple solution might be to add two optional reserved words to the
language -- 'function' and 'procedure' (synonymous with a void function).
Since C does not allow nested functions, they would act as resynchronising
operators -- the compiler should only accept them while it is parsing in
between functions. If encountered at any other time, they would signify an
error, but the compiler could reset its 'brace-counter' and hence resynchro-
nise.
Since the presence of these keywords is purely optional, they can be #defined
to nothing when ported.
Any comments, suggestions ?
-------------------------------
Another pet hate of mine are the C facilities for error handling, although
this may only be due to my ignorance of all the different methods in use.
The standard approach of many library functions such as malloc() and fopen()
is to return NULL or some other special value on failure. The biggest problem
with this is the way your program logic can get totally obscured with error
tests.
Another approach is to use printf's to stderr -- obviously unsatifactory in
many applications using wimdows (such as X, NeWS, curses, etc.). Even
setting up an error window seems a kludge unless the windowing environent
itself can be made to use it.
A third approach might be to set up nested setjmp/longjmp frames, so that even
library routines will longjmp rather than return error statuses (statii ??).
This seems to suffer a lack of an ability to diagnose the error from within
the error routines unless the important variables are global. How would you
'RESUME' or 'RETRY' the operation that caused the error?
The last approach I can think of is similar top the use of 'matherr' to catch
Division by zero and sqr(-1) type errors. This approach would seem to answer
the question above -- but only if the language implements dynamic varaible
scoping (which it doesn't, of course).
I realize that my comments and questions are rather vague, but is there a
generalized approach to error handling that could incorporated into the
language, that could ease construction of user friendly (read: idiot-proof)
software ?
Ron
--
Ron van Schyndel rdt155r@monu6.cc.monash.oz (...oz.au)
The Department of Physics, rdt155r%monu6.cc.monash.oz@uunet.UU.NET
Monash University (Caulfield Campus) {hplabs,mcvax,uunet,ukc}!munnari!monu6..
PO Box 197, CAULFIELD EAST, Phone:+613-573-2567 Fax:+613-573-2748