The IO framework of C3, which I have railed about elsewhere, uses exceptions internally in a very clever way: when a field is not in the correct format, the usual Smalltalk methods for conversion tend to throw exceptions.  The IO framework handles these exceptions and converts the field to its own liking.

We went a long time without knowing this (the evils of frameworks will be taken up elsewhere), and for a long time we had a small percentage of bad data coming in to the system and never knew it, because the exceptions were being handled inside the IO framework.

Once you know this is happening, you're still in trouble.  Unless you remove the handler, you can't debug in the area, because the framework's handlers will catch all the events before the debugger gets a chance to intervene and let you look around.

Even worse is the tiny detail that Gemstone's exception handling is slightly different from VisualWorks: Gemstone handlers are still active even after the exception has occurred.  So that an exception inside a handler ...  --RonJeffries
----
This doesn't strike me as a problem with exceptions ''per se'', but rather
with a particular framework's decision to silently catch and "correct" exceptions (and possibly with particular implementation issues).
This could have happened in any context in which the framework detected and
"corrected" malformed data, not just an exception-based one.

There may be a pattern lurking here concerning ThinkThriceBeforeEatingExceptions or something, perhaps a variant on ThrowDontCatch; that would be consistent with my experience: just as exceptions
tend to be caused by events outside the system, often the only way to handle them is to similarly report them outside the system, e.g. log them or report them to a user (or at least to do that in addition to any attempted correction).  But this doesn't argue AvoidExceptionsWheneverPossible.
Note that
if your framework ''hadn't'' munched the exceptions, they would have propagated
up to a point where they would at least have been reported.

Perhaps a better fix would be for the framework to replace the "fixed" values
with ones flagged as "fixed" (in the same way some accounting/tax software flags
values based on incomplete or questionable calculations).

--JimPerry

----

I agree with JimPerry here.  The IO framework should not have been doing
that.  Either (a) the IO framework had an implementation bug, namely that it should have
treated poorly-formatted values differently, or (b) the IO framework
was misconceived, i.e. it was doing what its creators intended, but
they should never have intended that.

The fault here lies not in the exception mechanism, but probably in the
fact that the designers of the IO framework didn't have a clear concept
of what exceptions were really for.  Or, if you want to give them
less benefit-of-the-doubt, they were using exceptions to paper over
a real problem, pretending that the problem wasn't there.  If the
convention was to use error codes instead of exceptions, the same
problem could have arisen in much the same way.

-- DanWeinreb

----

I agree, it looks like you really don't need exceptions to build the problem Ron describes. A few years ago I was actually acquainted with a person calling themselves a programmer who decided it would be good for reliability of a 24/7 system to handle all signals. Yes, including SIGSEG and SIGKILL. The same fellow had actually escaped 3 times from a Vietnamese prison camp and lived to tell the tale, so I think he gets points for determination ... but you get the idea.

So we're still left with the notion that exceptions are good some time, and bad some time, and we need a criterion to decide which is which. Masking real problems is definitely bad, but I don't think it's the only bad use. --PeterMerel

----

''"the framework's handlers will catch all the debugger's attempts to tell you things."'' - Interesting point. It doesn't happen in Java et al, because the debugger doesn't use exceptions like that. The debugger has its own MetaObjectProtocol for messing with the JVM. However, Java does have subclasses of Error which are for reporting Meta Object problems and programmers are strenuously advised not to catch them unless they know what they are doing.

It sounds like either a flaw in Smalltalk that didn't let it distinguish debugger exceptions from normal ones, or a flaw in the framework that didn't take advantage of the distinction. -- DaveHarris

-----

VisualBasic, by default, will break to the debugger whenever an exception (error) occurs, even if there are proper error catching handlers.

''(In practice, I find this feature more annoying than useful, and set the option to "break on unhandled errors."  Otherwise the debugger pops up every time we use our "Is''''''In''''''Collection()" function to see that a given key is >not< in a Collection.  Yes, it would be better if VisualBasic's Collection class had a method to test presence of a given key; but it doesn't.)''

Right: Exceptions weren't really the problem in the SmalltalkLanguage I/O Framework above.
Consider the position "things would have been so much better if they hadn't used exceptions."
In that case, they'd probably check the validity of the data before converting it ''(duplicating code)'', and still inserting their guesses as to the "right" values.
I suspect that lack of exceptions would have made the problem worse, by forcing a more obscure and redundant implementation ''(...assuming that the framework developers persisted in implementing their partially thought through "features")''.

Years of painful experience have taught me to have '''''zero''''' faith in data that comes from other systems.
''(Zero degrees Kelvin; "absolute zero!"  ;-)''
So I get really anal about validating every bit that comes into my systems.
-- JeffGrigg

----

This, like almost everything Ron has written about exceptions, is pure crap. The problem has nothing to do with exceptions, but everything to do with converting errors into non-errors ... in this case by '''catching''' exceptions in order to replace bogus input with something well-formed. The same could have been done with any other means of indicating errors. The fact is that it's '''the usual Smalltalk methods for conversion''' that use exceptions (for reporting errors), not the IO framework -- the IO framework uses the Smalltalk methods, and since they use exceptions to report errors it catches exceptions -- if it were using some other API, it would detect errors based on how that API provides them. Duh.
-- MarcelKincaid 

----
CategoryException