Subject: Re: [SWIPL] Type error vs. silent failure

From: "Richard A. O'Keefe" <[email-masked]>
Date: Mon, 29 Oct 2001 11:06:17 +1300 (NZDT)

Please reassure us that the "exception doesn't happen" cost is nothing
	to be afraid of :-)
	
	If not, is it inherently expensive, or could it e.g. be compiled as a
	special case?
	
I have just sent E-mail to Jan explaining how it is quite straightforward
to open-code if_error/3; the cost _shouldn't_ be much more than the cost of
a general if-then-else (push and pop a choice point, plus a couple of other
instructions), and can't be much less (because when an error occurs, all
the variables which were unbound when Goal started are supposed to be
unbound again).
	
	Java pragmatically distinguishes "checked" and "unchecked" exceptions,
	then imposes static checking on checked exceptions (must be either
	handled or explicitly declared to be possibly thrown).  Is it feasible
	to do such static checking on (some practically useful subset of)
	ISO or SWI Prolog?
	
It may just possibly have escaped your attention, but Java is a statically
typed language, and the Java check here is a type check.  It is not feasible
to do anything like this in any subset of Prolog without doing a reasonable
full type check.  You could add such a thing to Mercury, for example.  It is
no accident that Common Lisp (perhaps the most powerful condition handling
system in common use, as it is the most powerful object-oriented system in
common use) does not do this.

	PS I am not suggesting that it must be a good idea because Java does 
	it, but that software engineering issues like this are essentially
	pragmatic, not theological, and that there's been enough experience
	with the Java scheme for us to decide whether it was well judged or
	misconceived...
	
Well, there was enough experience a year after Java came out, and the verdict
was "HANG Java".  It has proven to be _always_ a nuisance and _seldom_ of any
benefit.  Amongst other things, it pushes up the development cost of making
compatible classes.  Suppose we have
    parent A with method f
      -- child B (may signal X in f)
      -- child C (may NOT signal X in f)
then A must say that f will signal X (or else B won't be overriding it),
and then C must falsely say that f will signal X (otherwise it won't agree
with its parent).  The really nasty thing happens when you have already
shipped A and C and then later add B and only then discover that it needs
to signal X.  And no, it is NOT always sensible or even practical to catch
X in B and turn it into something unchecked.