I think the approach they're pursuing --- print a message and exit
by default, allow the programmer to override that default if they
wish --- is the best possible solution.
Well-written code using facilities without exception management ends
up having a lot of clutter from error-checking. Sure, it's important
to do it right, but since the common case in many programming
contexts is to print an error message and exit, that's a good
default behavior --- especially for the sort of errors that might
be thrown from a string handling library, where there's little a
user (or application programmer) is likely to be able to do to help
correct a problem. If it's also reasonable to override that default
allowing explicit error handling where desired, then you meet
everyone's needs.
I last programming extensively in C back in the late '80s and early
'90s; when I was doing my heaviest C programming, I used a library
I'd built up, which I called libbent, containing eventually several
dozen wrappers following the model (from memory):
FILE *efopen(file *path, file *mode) {
FILE *fp;
if (fp = fopen(name, mode))
return(fp);
(void) sprintf(stderr, "%s: fopen(%s, %s): %s\n",
progname, path, mode, strerror(errno));
exit(1);
/*NOTREACHED*/
}
or thereabouts. If I wanted to handle an error myself I just called
fopen(), but in the common case I only had to add one letter, rather
than a clause.
Since then I've been programming almost exclusively in perl; my code
is pretty well larded up with "|| die ...", which fortunately isn't
quite as bulky as the C, but is still a distraction. I often use
Fatal to reduce the clutter, although it's not perfect either.
A security-minded library is well guided to offer the safest default
behavior, making it easy enough to override when a programmer wishes
to handle errors any other way.
-Bennett
This archive was generated by hypermail 2b30 : Tue Feb 11 2003 - 12:48:22 PST