Consider this valid java file "Porrage.java" made just for this example.
(creative commons terms apply).
import
java.lang.*;
class Porrage {
public class Exceptional extends
Throwable { };
public class TooCold extends Exceptional { };
public
class TooHot extends Exceptional { };
public final
void
Acceptable(int temp) throws Exceptional {
if (temp < 68) throw new
TooCold();
if (temp > 130) throw new TooHot();
return;
}
}
This exports a class "Porrage" and the following
"API"
public final void Acceptable(int) throws
Excpetional
Plain reading of the code shows that "Exceptional"
is never thrown. The user will have to "catch" it however, or pass it
on. This may or may not be a good API for this. [ASIDE: and note the similarity
to rangeCheck() /snark.].
Now, does the "API" throw one, two, or three
exceptions?
By formal definition it throws one. By factual analysis it
throws two. By proper coding you will need to deal with all three since you will
either have to catch all three; "TooHot" and/or "TooCold" are the data you want
to know, but since the signature says "Exceptional", someone somewhere is going
to have to write a catch for Exceptional to use this code.
This goes
directly back to the whole "formal API" vs "defacto API" discussion I previously
declaimed. Also, without a documentation element (or decompiling in the case of
Java per se) the API user would have to discover "TooHot" and "TooCold" by trial
and error.
So the defacto (true) API is whatever the java compiler gets
by cracking open and looking in the resulting .class files, and not any other
external definition. But the API is ALSO the formal spec, and/or the
"rules" and who knows what else.
This whole question is a result of
lawyering and not a result of the facts of the technology as it exists. Any
answer that is "responsive" to the question as written will compound the
errors. [ Reply to This | Parent | # ]
| 
