Can anyone tell me what reasons exceptions can have, not to be compatible with "throws" clauses
For instance:
class Sub extends Super{
@Override
void foo() throws Exception{
}
}
class Super{
void foo() throws IOException{
}
}
Exception Exception is not compatible with throws clause in Super.foo()
Without a full code sample, I can only guess: you are overriding/implementing a method in a subclass, but the exception specification of the subclass method is not compatible with (i.e. not a subset of) that of the superclass/interface method?
This can happen if the base method is declared to throw no exceptions at all, or e.g. java.io.IOException (which is a subclass of java.lang.Exception your method is trying to throw here). Clients of the base class/interface expect its instances to adhere to the contract declared by the base method, so throwing Exception from an implementation of that method would break the contract (and LSP).
To fix it use RuntimeException
public T findById(long id) throws RuntimeException {
try {
return whatEver.create();
} catch (SystemException e) {
throw new RuntimeException(e);
}
}
Hope this helps.
Checked exceptions are intended for use in situations where a method may expect its caller to be prepared to deal with certain problems that may arise. If callers of BaseFoo.Bar() are not required to deal with a FnordException, then method DerivedFoo.Bar() cannot expect its callers to deal with a FnordException either (since many of its callers will be the same ones that were unprepared to have BaseFoo.Bar() throw it).
Conceptually, that's great. In practice, not so much. The problem is that the design of checked exceptions in the language assumes that either no callers will be prepared to deal gracefully with a particular problem, or all callers will be prepared to deal with it. The normal state of affairs in practice is for callers to be unprepared to deal with exceptions--even those that some callers might be able to handle. Most of the time, the proper course of action when code receives a checked exception it's not explicitly expecting would be to wrap it in an unchecked exception and throw that. Ironically, the easiest course of action--adding a "throws" clause and letting the checked exception bubble up, is probably the one which is least likely to be correct. While there are a few cases (e.g. IOException) where such behavior would make sense (e.g. when trying to read a collection from a file, an I/O error while reading one item is an I/O error while reading the collection), an exception thrown from within a nested method call will represent a different condition than will an exception of the same type thrown by the outer method, and code which would be prepared to handle the latter may not be prepared to handle the former.
In your situation, your best bet may be to catch IOException and wrap it in some other type that derives from RuntimeException, being aware that your callers are unlikely to be able to handle it.
Make sure you declared throw in your interface. If you did, but the problem still persists - try saving/rebuilding the project.
