Develop Reference

Java generic exceptions for callable

Is there any way to get a class that explicitly throws the (non-runtime) exceptions and only the (non-runtime) exceptions that the body throws?
I know how to do this with a fixed number of exceptions, like:
public interface Throw1Callable<T, E extends Exception> {
public T call() throws E;
}
This way, when call is invoked, you don't have to handle Exception and instead only have to handle RuntimeExceptions and E. But this doesn't scale at all. If I wanted to do this for two exception, I'd need to make a new class for Throw2Callable etc. And Java (and probably all languages) doesn't offer variable number of generics or anything of the sort that might help.
Is there a good way of encapsulating the above?
edit for clarification: Let's say A.a throws IOException. I'd like to be able to do ((Throw1Callable)() -> A.a()).call() and catch only IOException instead of catching Exception. ((Callable)() -> A.a()).call() will throw Exception instead of just IOException.

This boils down to some kind of "vararg" type parameter which is not possible in Java.
So probably ThrowXCallable is the best you can do here. I don't think "scalability" is a big problem here, you will probably not need more than Throw5Callable.
Java itself takes this approach - see BiFunction.

Why do you need to catch "Exception" but not the Subclass "RuntimeException"?

The below picture shows that "Checked" and "Unchecked" Exceptions are subclasses of Exception. I find it confusing that you need to catch an Exception but you don't need to catch a RuntimeException, which directly inherits from Exception. Is there a reason that the devs didn't let us throw Exceptions without needing to catch them?
More specifically: Why can you ignore only RuntimeExceptions and it's children? Why wasn't there a Class introduced called CheckedException extends Exception and you only need to catch it and it's children?
The confusing part is, that you can throw everything below RuntimeException without issue, but when you move up to Exception in the hierarchy, you need to catch it at some point. This is confusing because "abstraction" normally works otherwise. The more you move up, the simpler and more meta everything gets. This is not the case here. The more you move up, the more you have to do (like, putting try/catch after reaching Exception).

If Exception was unchecked then you could implicitly cast checked exceptions to unchecked ones, which would mean that you could throw checked exceptions without catching them like:
public void f() {
Exception e = new IOException();
throw e;
}
and also with overriding methods, if you throw a more specific exception, you can add the requirement to catch the exception that wasn't in the superclass:
public void f() throws Exception {
}
...
#Override
public void f() throws IOException {
}

Suppose they designed it the other way. We have a CheckedException class, and subclasses of that need to be handled, but not other subclasses of Exception.
Now we call a method that might throw an arbitrary Exception:
public static void example() {
functionThatThrowsException();
}
Do we need to handle it? Yes, because that Exception might be a CheckedException. If we didn't need to handle it, we'd be bypassing the checked nature of checked exceptions.
A throwable type with checked descendants must be treated as checked, so checkedness naturally propagates up the inheritance hierarchy. Contrapositively, an unchecked throwable type cannot have checked descendants, so uncheckedness naturally propagates down. This makes it natural to make checkedness the default, and single out specific classes and their descendants as unchecked.

CheckedException (Which does exist) and RuntimeException both extend Exception. Because of this, if something throws a generic Exception (which is always a bad idea), there is no way to tell if the exception could be one or the other, so you have to catch it in case it's a checked one. If you think of the hierarchy in this way, it actually does get simpler the farther up you go.
You seem to have the idea that checked exceptions are more "complex" because you have to do more to work around them. This isn't too healthy a way of thinking about it. Instead, consider this: Exceptions are problems with the program itself - the code. We need to find these exceptions and handle them properly. After already having this concept of exception handling, we discover that there are some problems that we simply can't predict.
"How was I supposed to know the user would enter 'meow' when asked for an integer! I shouldn't have to code around that!" And so, NumberFormatException was born, and you don't have to catch it because it's a "logical error", not an issue caused by bad code (Although, arguably, it might be considered bad code if you don't handle this situation in some way).
In short, reverse your thinking. Exceptions are problems with the program that can be handled. There are some exceptions, however, that are unexpected and are a result of bad design more than incorrect code. Thus there is the addition of RuntimeExceptions which cannot possibly be expected to occur, but certainly can occur.

Perhaps it would help to not think of exception classes in terms of inheritance but simply disjoint sets of classes, one set is checked and other is not. You're right that there could be a CheckedException class allowing us to check only when explicitly intended.
However having the broader/generalized range checked helps in enforcing the catch or specify pattern. Having checked exception allows a reader of the code to figure out quickly that this piece of code needs special attention and enforcing their handling at compile time reducing the runtime bugs.
We can throw any kind of exception, checked or unchecked. If Exception or any super class of RuntimeException were to be set as checked exception then all the sub classes would become checked exceptions. As compiler is most likely checking if an instance of exception or a class in the throws clause derives from a class. It could easily have done that by checking for a specific package which probably would have been more appropriate as being checked or unchecked has simply nothing to do with the inheritance.

Should I declare all exceptions thrown from a method in the method signature or just the super class of the exceptions?

When I throw checked exceptions from a method should I just declare the super class of the exceptions in the method signature or all the different types? If I have the following exceptions:
private class SuperException extends Exception {
}
private class SubExceptionOne extends SuperException {
}
private class SubExceptionTwo extends SuperException {
}
Should the method signature be:
void confirmAccount() throws SubExceptionOne, SubExceptionTwo;
or
void confirmAccount() throws SuperException;
In the last method signature, how do I tell other developers what exceptions that could be thrown from the method? If the different sub types need different handling?

The interface should be as stable as possible. So probably Super. Many libraries use the "Super" strategy, because exception specs cause far more annoyance in maintainability than readability or safety they add. Even the IOException is a Super that nearly all Java library code uses instead of declaring more specific exceptions. (But when they do declare more specific exceptions, it's because the contract is that more general IOExceptions won't be thrown. Read on.)
You might list Sub1 and Sub2 if you really do want to say each of those exceptions can be thrown, but don't want to say that any derivative of Super can be thrown. Perhaps Sub1 is NumberCrunchException and your method calls crunchNumbers() and users of your method can be assured that's the only exception-ful thing your method does. In that case the specific strategy is better.

If the different sub types need different handling, then definitely declare the two different exceptions. Never expect the developer using your method to guess that you are actually throwing different types of exceptions.
If you declare two distinct exceptions, and the user knows from the Javadoc that they are actually descendents of the same class, the user may choose to catch them both with a catch (SuperException e) rather than two individual catch clauses. But it depends on the user's choice.
If you don't declare them separately, your IDE is not going to add the appropriate #Throws to your Javadoc comment. And your Javadoc will therefore only indicate that you're throwing SuperException, which will leave the user in the dark. Solving this by just putting it in the text of the comment is not a real solution. If any tool is using reflection to determine what your method throws, it will not see the individual exceptions in the array returned from Method.getExceptionTypes().
If the functionality expected of the different exceptions is more or less the same and it's just a matter of how they will appear in the logs, it may be better to just use the parent exception, with different messages.

The throws clause is there to convey useful information to the calling method about what might go wrong during invocation of this method. That means that how specific you are will depend on how much information you want to convey; and that will be application-dependent.
For instance, declaring throws Exception is almost always a bad idea: the information this conveys is just "something might go wrong", which is too vague to be useful. But whether calling classes are going to need perfectly fine-grained information in the throws clause is something you need to decide by looking at your program. There's no set answer.

Throw anonymous exceptions in Java

It is possible in Java to throw any Exception even if it is just declared on moment of throwing, example below:
import org.springframework.dao.DataAccessException;
// DataAccessException - is abstract class
} catch (DataAccessException dae) {
throw new DataAccessException("Exception while executing SQL: \n" + sql
+ "\nparams: " + paramsToString(params), dae) {
private static final long serialVersionUID = 1L;
};
}
Please share your ideas how bad or good this approach.
the same question to extending RuntimeException (that is not abstract) and throw it right away.

Please share your ideas how bad or good this approach.
It should be legal ... according to my understanding of the Java language.
I think it is pointless from a functional perspective. The caller still has to catch the base exception that you created the anonymous subtype of. And it is not like the name of an anonymous subclass conveys any useful information ...
I think it is bad from the perspective of code readability and maintainability. It is obscure for no good reason, and no useful effect that I can discern.
And there is a risk that doing something weird like that it might break things .... such as your debuggers, source-code analysers or some other tool in your Java chain.
In summary, it is a bad idea with no redeeming features.

Yes. Your example is perfectly okay. An Exception instance is just a class (that extends Exception) name plus information that will be needed when it's caught. Often the class name is all you need (for the catch statement). Normally a message and a stack trace are included. (Though they're both rather useless for caught exceptions.) But sometimes more info is needed. Extending a class is one good way to do that.
If performance matters (which when working with SQL it might not) override fillInStackTrace. Filling in the stack trace is slow, and if you're planning to catch the exception, you don't need it.
Don't extend RunTimeException; you won't be warned about methods that could throw it and you may forget to catch it.

Java: What is the proper way to declare an interface method that can throw an exception?

Let say I have this interface A that is implemented by multiple vendors:
interface A
{
void x();
void y();
}
However, I want vendors to be able to throw exceptions to signal something has failed and potentially the method could thrown a RuntimeException. In each case, the code that calls these methods should handle the failure and continue. Just because 1 vendor throws an NPE, I don't want the system to come crashing down. Instead of leaving it up to the person calling the method (or really down the line maintainence), I would like to make sure each call will catch all exceptions by declaring each method as:
void x() throws Exception;
but this is generally bad practice (PMD doesn't like it and generally I agree with the rule for concrete methods) so I wonder is this an exception to the rule or is there a better way?
Let me be clear, I'm looking for a solution where the caller of the interface is forced to handle all exceptions (including RuntimeExceptions).
To further detail my environment, all of this is running within an OSGi framework. So each vendor packages their code in a bundle and OSGi will handle all exceptions to prevent the entire system from crashing. What I'm really looking at are OSGi service interfaces that will be called by some core bundle. What I want to make sure is that when I iterate through all of the services, one service doesn't throw an NPE and stop the process that is executing. I want to handle it more gracefully by catching all exceptions thrown from the service so the other provided services are still managed.

Create your own Exception class ie. MySeviceException and throw it from the interface. The idea here is to throw meaningful exceptions so don't be afraid of creating many custom exception classes if that provides most readability and maintainability for your purposes. You can catch the vendor detailed exceptions in the downstream and wrap them as your custom exception so that the upstream flow does not have to deal with vendor specific exceptions.
class MySeviceException extends Exception{
public MySeviceException() {}
public MySeviceException(String msg) { super(msg); }
public MySeviceException(Throwable cause) { super(cause); }
public MySeviceException(String msg, Throwable cause) { super(msg, cause); }
}
interface A
{
void x() throws MySeviceExceptionException;
void y() throws MySeviceExceptionException;
}
As a rule of thumb never catch Errors, always catch Exceptions and deal with it!

Vendors can certainly throw RuntimeException to their heart's content, because they're unchecked. That means you don't have to add the throws clause to the interface.
It also means that clients won't have any warning from the interface definition, and the compiler won't enforce a required try/catch. The only way they'll know is to read your Javadocss.
You can create a custom exception that extends java.lang.Exception; that's a checked exception. You'll have to add it to the throws clause; the compiler will enforce a try/catch around those methods; your clients will have to handle the problem.

I would avoid placing the exception throw in the interface because of limitations that you force on implementers. If I must throw an exception by implementing your interface, it will make mockups for testing more difficult.
If something goes wrong in the code that implements your interface, that should be the concern of the programmer of the implementing class.

I agree with PMD - declaring that you throw generic Exceptions is ugly. I think it is better to
Define new, domain-specific, non-runtime exception classes (if the built-in-ones will not do; always stick to predefined classes if you match their semantics), and declare them in the methods that can throw them
Keep runtime exceptions to a bare minimum. They only make sense when you have no control over how you are called, and nothing else will do. If you have any reason to expect them to be thrown in a piece of code you are calling, then catch them as early as makes sense and re-throw them as standard exceptions (see above point).
Recent versions of Java allow you to chain exceptions. For example, if you get a NullPointerException ex while parsing a File f with an external library, you would want to catch it and rethrow it as, say, a new FileParsingException("error parsing " + f + ": " + ex.getMessage(), ex);

Depending on your JVM settings, any method has the ability to throw a RuntimeException whether you declare it as throwing Exception or not. Catching/handling RuntimeExceptions is generally a bad practice. While there are some limited cases where this behavior could be required, RuntimeExceptions are primarily an indicator that there is something wrong with the code, rather than the usage of the product. Of course, a major downside to catching RuntimeExceptions (especially if you're ignoring them) is that things could be blowing up in your system and you have no idea that it's happening...then all of a sudden, your system spits out completely invalid data, or crashes anyway from some other reason, making it more difficult to track down the root cause.
See Sun/Oracle's tutorial about exceptions
http://download.oracle.com/javase/tutorial/essential/exceptions/runtime.html
To answer the question, unless you know exactly what Exception derivative you can expect to be throwing, you're pretty much stuck throwing Exception, though I have major doubts as to the usefulness of throwing the generic Exception class, unless you only care about logging out the stack trace and such so that you know it happened? If you're trying to robustly handle the Exception without knowing what kind of Exception it is, then you probably won't be very successful in handling it properly or even well-enough.

Creating a throws clause, even with a custom exception type, is not really an answer here. You are always going to have things like NPEs. Even if you specify to the vendors that all exceptions must be wrapped in your custom exception type there are going to be cases where somebody makes a mistake and an NPE gets through. If it wasn't for mistakes you wouldn't have NPEs.
Adding "throws Exception" is a bad idea in a lot of cases, but in some cases it works out. In frameworks like Struts and JUnit you can add "throws Exception" without a problem because the framework allows for it. (JUnit wouldn't be very useful if the first exception thrown made the test suite halt.)
You could design the system so that calls to vendor code happen in specific modules that get plugged into the system and which have exception-handling taken care of by the system, similar to how Actions work in Struts. Each Action can throw anything, there's an exception handler that logs what went wrong. That way the business logic that calls into vendor APIs wouldn't have to be bothered with useless exception-catching boilerplate, but if something goes wrong the program doesn't exit.

You could implement your interface in an abstract class that uses the template method pattern to catch and wrap RuntimeExceptions with a custom exception. However, there is no way to enforce that the vendors use the abstract class (other than documentation).
class MySeviceException extends Exception{
public MySeviceException() {}
public MySeviceException(String msg) { super(msg); }
public MySeviceException(Throwable cause) { super(cause); }
public MySeviceException(String msg, Throwable cause) { super(msg, cause); }
}
interface A
{
void x() throws MySeviceExceptionException;
void y() throws MySeviceExceptionException;
}
class ABase implements A
{
public final void x() throws MySeviceExceptionException {
try {
doX();
} catch(RuntimeException ex) {
throw new MySeviceExceptionException(ex);
}
}
public final void y() throws MySeviceExceptionException {
try {
doY();
} catch(RuntimeException ex) {
throw new MySeviceExceptionException(ex);
}
}
public abstract void doX() throws MySeviceExceptionException;
public abstract void doY() throws MySeviceExceptionException;
}