Re: How to tell caller of an error if you cant change the signature
of a method
Lew wrote:
Pretty much any time I see run-time type checking built into the code, I
think, "This is a job for generics!"
Well, a job for polymorphism primarily, and generics frequently.
Owen Jacobson wrote:
That works for single exceptions (and it's probably how I'd do it
under the constraints), but not all services only throw one type of
exception that's more specific than Exception. Other approaches are
necessary if you want to make the exception handler interface specific
to the exceptions that can actually be thrown, for these services.
I see that done without run-time type comparisons all the time. Why would
they be needed?
try
{
doSomething();
}
catch ( SomeKindOfException exc )
{
// handle exc
}
catch ( SomeOtherKindOfException exc )
{
// handle exc
}
OK, maybe the problem is that I said "run-time checking". To me this is
compile time - each block is written with total confidence in the exception
type, and without the need for explicit, coded-in checks performed at run
time. The compiler generates all the necessary code. So from my mental
stance, I handle all the type checking at compile time, the *JVM* handles the
run-time checks. Polymorphism is the same thing - I handle the type at
compile time, the JVM dispatches to the right object at run time. Obviously
everything that happens in a program happens at run time. There is a
difference as to where the *code* places the checks. With expressions like
if ( exc instanceof SomeKindOfException ) ...
the programmer explicitly invokes a run-time comparison. With the
compile-time constructs, the programmer leaves it to the platform.
--
Lew