Re: Why does Java require the throws clause? Good or bad language
design?
Arthur J. O'Dwyer wrote:
On Mon, 19 Feb 2007, Michael Rauscher wrote:
catcher calls higherLevel, so one contract is between catcher and
higherLevel.
higherLevel calls cbf, so there's another contract: between
higherLevel and cbf.
FWIW, you're wrong. The "contract" is obviously between the main
function 'catcher' and its helper function 'callbackFunc'. Now, I'll
agree that Java does not let us /express/ that contract; but that's
not the same thing as its not existing in the first place.
You can't just ignore the higherLevel method.
Let's assume a specification that tells us that a value of 42 must not
be passed to callbackFunc. Further, assume there'd be a contract between
callbackFunc and catcher telling catcher.
Now, let's rewrite higherLevel:
void higherLevel( (void)(*cbf)(int), int arr[], int n ) {
try {
for ( int i = 0; i < n; i++ )
cbf(arr[i]);
} catch ( char *e ) {
}
}
With this, catcher will never catch an exception.
And now? What's about the contract between catcher and callbackFunc?
There are two things to mention:
1. callBackFunc is not defined, yet.
2. If one looks at CBF one can see the obvious contract that must be
fullfilled when calling or *implementing* CBF#execute:
- the caller must provide one argument of type int.
- execute does not throw a checked exception.
3. 'catcher' doesn't contain a 'catch' clause, which makes its
name misleading at best. ;)
lol. I'm sorry. I have to concentrate on writing in English, so 3.
didn't came to my mind. I'm happy enough, if my writings don't contain
too much of incorrect English :)
Back to the topic:
catcher needs no catch clause since the contract contains no rule for this.
One may add a catch clause in order to catch unchecked exceptions, of
course.
"Unchecked exception" being the Java equivalent of C++'s exceptions,
right? That is, they behave the same way as checked exceptions, but you
don't have to declare them in exception specifications.
Yes. E.g. dividing by zero would result in an ArithmeticException. As
Lew mentioned, checked exceptions are part of the contract - unchecked
are not.
or if you a checked exception should be thrown,
declare it in CBF#execute's throws-clause.
That would be nice, but you just said that Java won't allow you to
do that. ("This would lead to a compile-time error ...") Unless of
The example above ("This would lead to a compile-time error") was
related to the throw statement. This time I referred to the throws clause.
course you propagate the exception specification all the way up into
'higherLevel', which would mean no code reuse in the presence of
checked exceptions.
I don't see anything that would be against code reuse.
If there's a throws clause it only means that an exception /might/ be
thrown. There's no need to throw an exception.
Example:
interface CBF {
public void execute( int x ) throws Exception;
}
Now, the Exception is part of the contract and higherLevel must take
care of it.
void higherLevel( CBF cbf, int arr[] ) throws Exception {
for ( int i = 0; i < arr.length; i++ )
cbf.execute(arr[i]);
}
The compiler ensures that the Exception is handled.
Bye
Michael