I have a service that allow users to add dynamic content to a repository. So basically I have a generic Document class that contains a list of property for that specific object depending on what type of document the user is adding (eg. an invoice document has an invoice number property while a wiki document has an author property, and so on).

The service is comprised of different layers and at some point I have a class that has to check if the document to be added is compliant to the rules configurer, evaluating if all required properties are provided, if they are all of the right type, etc. If any of these validations fail I want to throw a custom exception which contains the validation status.

The question is:

  • Should my ValidationException be checked or unchecked?

I read a lot of best practice on how to decide what kind of exception use. I was thinking about using RuntimeException but in this case the exception is not caused by error in coding or stuff like that but just by the user input...

On the other hand using a checked exception would mean to propagate the "throws" syntax in all the above layer of the application and probably in the 90% of the service's methods making the code much less readable and maintainable.

  • Why use an exception for something you expect to happen? Why not a returncode?
    – Pieter B
    Commented Aug 8, 2014 at 13:22
  • @PieterB I thought about using that but it sounded a little weird to me. My main concern is that the validation process is something internal to the engine so, when the user calls something like: addDocument(Document doc); I would like to return to him other stuff like document id, I feel more natural if the validation would be handled just like I would check for a null pointer exception throwing the exception back to the user if the input document is not valid. Also, since this is exposed by as a REST-API I'd rather return a 500 (or better a 400 in this case).
    – Nicola
    Commented Aug 8, 2014 at 13:34
  • imo the class that does the validating shouldn't throw exceptions, the caller should.
    – Pieter B
    Commented Aug 8, 2014 at 13:35
  • I have different layers, the core layers where validation comes in are: rest-service-layer ==> business-layer. The rest layer parses the request from the user and calls the main business method addDocument in the business layer. addDocument calls the validationService and if its all right goes on doing its stuff. addDocument could be called also internally by other places in the business layer. If I choose not to throw an exception in the validation process, addDocument has somehow to signal that it has created the document. You would throw an exception there or return some value?
    – Nicola
    Commented Aug 8, 2014 at 13:47
  • If you want to throw an exception I would throw it in the addDocument method. Because adding the document failed because: not valid or file not found or diskspace exhausted etc.
    – Pieter B
    Commented Aug 8, 2014 at 13:58

2 Answers 2


I think Oracle docs can't be more explicit about it:

Generally speaking, do not throw a RuntimeException or create a subclass of RuntimeException simply because you don't want to be bothered with specifying the exceptions your methods can throw.

Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception.

Source here...

You are the only one who knows if this is the case.

I believe that the real problem is not whether it should be a checked or an unchecked exception, but the many levels you would have to propagate the checked exception (as you said) for it to be properly handled. Perhaps you could tell us a little bit more about your design.

  • +1 for resorting to an authoritative source's recommendation and quoting it accordingly. Commented Aug 8, 2014 at 15:19
  • I think part of the reason for this question is that referring to Oracle's guidelines is an argument from authority. C# didn't include checked exceptions into the language because the designers consider them troublesome. That means Microsoft is implicitly arguing that they shouldn't be used. I could then ask why someone should trust Oracle's advice over Microsoft's or vice-versa. I'm not downvoting you over this but it's not a very satisfying answer.
    – Doval
    Commented Aug 8, 2014 at 15:20
  • @Doval Since he's using Java I thought he might as well use Oracle's way of thinking. I agree with you though on that you should have some solid reason to trust one over the other in this controversy over checked/unchecked exceptions Commented Aug 8, 2014 at 15:31
  • An added source is Joshua Block (Effective Java 2nd edition Item 58). Note that if you are passing an exception on for many levels, you probably aren't handling it at the right level. You might need to wrap so the higher layers don't know the details of the lower layers (instead of catching 27 different validation errors, at some point wrap all validation mistakes that can happen into one general one). See item 61 of effective java. (PS the reason I don't use exception in C++ is that you can so easily forget to catch them, so checked exceptions are very helpful because they are troublesome)
    – Thirler
    Commented Aug 9, 2014 at 13:18
  • 1
    After a weekend spent thinking about this, I think I will go for the checked exception. There is not so much space in the comment but I'll try to summarize: the internal validation method won't throw any exception, intead it will return a ValidationResult object containing what is wrong with the input: by doing this I will be able to reuse the method somewhere else without having to catch errors. In the business layer the DocumentService will throw a checked ValidationException. finally the ServiceLayer will handle this kind of exception and turn it into a specific 400 (bad request) code.
    – Nicola
    Commented Aug 11, 2014 at 8:22

You should use a checked exception so that the compiler always reminds you to catch it.

If the validation fails you want to catch that error anyway so why use unchecked exceptions and maybe forget that this exception can be thrown.

For more details on this particular case you can also read: http://learnjava.today/2015/11/checked-vs-unchecked-exceptions/

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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