Re: How to tell caller of an error if you cant change the signature
of a method
On Apr 14, 8:04 am, Jan Thom=E4 <k...@insomnia-hq.de> wrote:
On Mon, 14 Apr 2008 07:31:39 -0400 Lew wrote:
No other way, except to wrap the class in another class that throws the
exception, or to handle the exception invisibly such as by returning 'nu=
ll' or
an empty array, or by using a completely different API that doesn't have=
the
restriction,
What do you bet that there is no other way than those?
Okay for the sake of nitpicking there are a bazillion other ways of doing
it. However I implied that
- the OP has to use the provided interface
- cannot change the provided interface
Therefore you can either hack something into the return value, which is
impractical as the caller cannnot find out what went wrong (as the OP
clearly stated) or you throw RuntimeExceptions which are not checked by th=
e
compiler. Or you can invent some kind of messaging service into which the
called function pushes it's error code and the caller retrieves it, but i
thought we speak about practical solutions here...
Jan
I don't think that's an entirely impractical solution:
public interface ExceptionHandler {
public void handleException (Exception e);
}
public class MyFoo implements IFoo {
private final ExceptionHandler eh;
public MyFoo (ExceptionHandle eh) {
this.eh = eh;
}
public String[] readStrings () {
try {
// Read from a file and possibly throw IOException
} catch (RuntimeException re) {
throw re; // propagate unchecked exc. untouched
} catch (Exception e) {
eh.handleException (e);
}
}
}
There are infinite variations on this; you could, for example, make
readStrings rethrow checked exceptions as RuntimeExceptions if eh is
null, or remove the bypass for unchecked exceptions and make
ExceptionHandler deal with Throwable instead of Exception.
Sure, it's clunkier than the natural solution: the exception handler
is lexically separated from the code that can throw an exception.
However, if the interface really is immutable, this might be the
cleanest way I can think of to retain the checked-ness of exceptions
without changing the interface.
For completeness, here's an ExceptionHandler that knows about
IOExceptions:
public class IOExceptionHandler implements ExceptionHandler {
public void handleException (Exception e) {
try {
throw e;
} catch (IOException ioe) {
System.err.println ("Handled an IOException: " + ioe);
} catch (Exception e) {
// Unexpected variety of failure here.
throw new RuntimeException (e);
}
}
}
As illustrated, the design of ExceptionHandler as written demands that
implementations be prepared for *any* Exception, even if the caller
will only ever pass some specific type of Exception. The design could
be improved by providing specialized ExceptionHandler interfaces for
different implementations of IFoo, such that each handler only has to
deal with the exceptions that can actually be thrown.
-o