When should one wrap runtime/unchecked exceptions? What is the need?
Why was CompletionException
in java8
introduced? There are other examples as well in java and please include as many examples you want to include.

- 22,664
- 11
- 59
- 87

- 964
- 1
- 9
- 26
-
whenever you vote for close, please choose to comment your reason. It might help as feedback. – singhsumit Sep 10 '15 at 16:19
-
You don’t. [`CompletableFuture`](http://docs.oracle.com/javase/8/docs/api/?java/util/concurrent/CompletableFuture.html) does. – Holger Sep 10 '15 at 17:03
-
[CheckedExceptions are an unnecessary anti-pattern!](http://www.vertigrated.com/blog/2014/10/checkedexceptions-are-an-unnecessary-anti-pattern/) – Sep 10 '15 at 17:08
-
@Holger question is not who does it but why? What is the need? – singhsumit Sep 11 '15 at 08:41
-
1See [here](http://stackoverflow.com/a/27430782/2711488) and [here](http://stackoverflow.com/a/31340386/2711488) – Holger Sep 11 '15 at 09:13
-
@JarrodRoberson the question I want to ask and you trying to link are very different. The question marked as duplicate is also irrelevant for me – singhsumit Sep 11 '15 at 10:02
-
@Holger so the way I see is that if there is some runtime exception while executing thenAccept or whenComplete code then we want to differentiate it with runtime exception thrown by future themselves. To do this it is wrapped in CompletionException. is it? this seems very weak motivation so I am surely missing something – singhsumit Sep 11 '15 at 10:04
-
That’s the motivation behind [`ExecutionException`](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ExecutionException.html), [`ExceptionInInitializerError`](http://docs.oracle.com/javase/8/docs/api/java/lang/ExceptionInInitializerError.html), [`InvocationTargetException`](http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/InvocationTargetException.html), [`UndeclaredThrowableException`](http://docs.oracle.com/javase/8/docs/api/java/lang/reflect/UndeclaredThrowableException.html) and many more. Generally,it’s the motivation behind creating different exception types at all – Holger Sep 11 '15 at 10:28
-
yes i was trying to mention execution exception when i was writing the question but it slipped off my mind and i couldnt recollect.. the reason i find it weak is as if i get NPE (null pointer) then its good looking exception in itself, why wrap it.. – singhsumit Sep 11 '15 at 11:02
-
anyways thanks a lot for your time and if you feel there is more explanation or some other aspect, please let me know – singhsumit Sep 11 '15 at 11:03
1 Answers
I wrap checked exceptions whenever I introduce an interface. For example if I had an interface
public interface DoSomething { void doSomething() throws DoSomethingException }
With my own checked exception class DoSomethingException
. This is because I'm making a contract with clients of the interface that only that exception will be thrown. This decouples clients from the exceptions thrown by implementations of DoSomething
. Whether or not I catch RuntimeExceptions
and wrap with my checked exception I approach on a case-by-case basis. For example, if an implementation of DoSomething
used a class that threw RuntimeException
s frequently enough, I would catch the RuntimeException
s and wrap them in my checked exception.
The java.util.concurrent.CompletionException
introduced in Java 8 is part of the concurrent package which indicates it's use is for the new concurrent tooling introduced in Java 8. For example, https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletionStage.html

- 16,923
- 6
- 62
- 75
-
thanks for your answer. I understand the need of wrapping in case of checked exception and my question is for unchecked exception. Another question that I asked to ask the same thing is that why was completionException class introduced in java8? – singhsumit Sep 10 '15 at 16:17