0

I have a method in my application service that receives the id of an entity:

 Document doStuff(Long documentId);

In my method I'm checking that the id passed match an entity stored previously, if not it throws an exception.

Now, my doubt is, is this com.application.exceptions.DocumentNotFoundException a RuntimeException or an Exception?

Should the Service force who use it to manage the case the id is wrong, or is it implicit?

rascio
  • 8,968
  • 19
  • 68
  • 108
  • 3
    It's both. It inherits from RuntimeException, and every exception inherits from Exception itself. http://docs.oracle.com/javaee/6/api/javax/persistence/EntityNotFoundException.html – Kakalokia Oct 23 '13 at 08:40
  • it depends what you wanna do, but RuntimeException is useful but you don't need to declare thows in methods... – ZaoTaoBao Oct 23 '13 at 08:45
  • sorry...I was talking not about the `javax.persistence.EntityNotFoundException` but something like `it.my.application.DocumentNotFoundException` – rascio Oct 23 '13 at 08:50

5 Answers5

2

As reference:

enter image description here

Runtime Exceptions (unchecked exception)

A RuntimeException class represents exceptions that occur within the Java virtual machine (during runtime). An example of a runtime exception is NullPointerException. The cost of checking for the runtime exception often outweighs the benefit of catching it. Attempting to catch or specify all of them all the time would make your code unreadable and unmaintainable. The compiler allows runtime exceptions to go uncaught and unspecified. If you like, you can catch these exceptions just like other exceptions. However, you do not have to declare it in your “throws" clause or catch it in your catch clause.

In addition, you can create your own RuntimeException subclasses and this approach is probably preferred at times because checked exceptions can complicate method signatures and can be difficult to follow.

Why is it not advisable to catch type “Exception”

Exception handling in Java is polymorphic in nature. For example if you catch type Exception in your code then it can catch or throw its descendent types like IOException as well. So if you catch the type Exception before the type IOException then the type Exception block will catch the entire exceptions and type IOException block is never reached. In order to catch the type IOException and handle it differently to type Exception, IOException should be caught first (remember that you can’t have a bigger basket above a smaller basket).

Maxim Shoustin
  • 77,483
  • 27
  • 203
  • 225
1

I think you meant to ask is whether its a checked or unchecked exception; it is unchecked as we see.

If you mean to declare your exception class - it shall follow the same path, ie create a unchecked exception.

Raúl
  • 1,542
  • 4
  • 24
  • 37
0

http://docs.oracle.com/javaee/6/api/javax/persistence/EntityNotFoundException.html

EntityNotFoundException is a RuntimeException which is an Exception. Although keep in mind that unhandled RuntimeExceptions will compile.

You should use an EntityNotFoundException

CamW
  • 3,223
  • 24
  • 34
  • ops not the one from javax.persitence but something like `it.my.application.DocumentNotFoundException` I mean... – rascio Oct 23 '13 at 08:48
0

As EntityNotFoundException is derived from 

javax.persistence.PersistenceException

and PersistenceException derived from java.lang.RuntimeException

so straight froward you should extend 

java.lang.RuntimeException.
Sai prateek
  • 11,842
  • 9
  • 51
  • 66
0

Now, my doubt is, is this com.application.exceptions.DocumentNotFoundException a RuntimeException or an Exception?

We can only answer that question if we see the sourcecode of your exception class and its superclasses.

  • If RuntimeException is a superclass, then your exception is a RuntimeException; i.e. an unchecked exception.

  • Otherwise, if Exception is a superclass, then your exception is an Exception; i.e. it is a checked exception.

  • Otherwise, you are "breaking the rules" by declaring a subclass of Error or a (heaven forbid!) Throwable. (In the former case, the exception is unchecked. In the latter case ... you are asking for trouble!)

Should the Service force who use it to manage the case the id is wrong, or is it implicit?

That is for you to decide, based on the semantics of that method ... and your API in general. And it is a matter of opinion whether checked exceptions are a good idea or not. But here are the criteria I would use to decide:

  • If it is "a bug" (i.e. a programming error) for that method to be called with an invalid id, then it is advisable to make it an unchecked exception.

  • It it is an issue where you would expect the application to try to handle the exception, then it is advisable to make it a checked exception ... so that the programmer won't forget.

You need to make these judgements on a case-by-case basis.

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216