Uncle Bob says in Clean Code book that Unchecked Exceptions should be used. Now JDK has some checked exceptions: IOException, IllegalAccessException etc. which cannot be avoided.

In my application logic suppose I have an exception:

public class MyDomainException extends RunntimeException {
    public MyDomainException(Exception e) {

And some code

try {
} catch (IOException e) {
    throw new MyDomainException(e);

Is this a good approach or should these checked exception be propagated up the ladder and filling the method signatures?

Edit: I understand this was asked and answered.

Can MyDomainException be used for business logic validation too or this exception should only be used for wrapping and other exception(s) should handle the business logic?

Edit: I would still like an answer to this question.

  • What about the second question? Should I open another question or can this be reopened / edited? – m3th0dman Mar 24 '13 at 13:32
  • Yes. Edit the second question out of this post and ask a new one. – ChrisF Mar 24 '13 at 14:22

It's good style. For example Spring's JdbcTemplate makes the same with JDBC exceptions.

From Spring documentation:

It(JdbcTemplate) also catches JDBC exceptions and translates them to the generic, more informative, exception hierarchy defined in the org.springframework.dao package.

| improve this answer | |

It depends, I understand Uncle's Bob's philosophy on this, but sometimes you want to capture the CheckedException and deal with it there and then. The example you use of catching, wrapping and throwing is fine, especially under Java 7 which does a better job of maintaining the hierarchy of exceptions.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.