0

In IntelliJ I'm working on some code that retrieves entities from Google Cloud DataStore, using a try catch block like this:

    try {
        T dataAccessObject = class.newInstance();
        entity = datastore.get(KeyFactory.createKey(dataAccessObject.GetEntityName().toString(), id));
        dataModel = (T)dataAccessObject.ToModel(entity);

        return dataModel;
    } catch (EntityNotFoundException e) {
    } catch (InstantiationException e) {

    } catch (IllegalAccessException e) {            

    }

To me, the empty catch statement for the EntityNotFoundException is a code smell, and I'd rather remove it and allow the exception to be thrown.

When I remove that catch statement however, it causes a compiler error, and I'm not seeing any explanation or rationale as to why removing the statement is invalid.

The datastore.get is calling something that implements the com.google.appengine.api.datastore.DatastoreService interface, which means it's possible for an EntityNotFoundException to be thrown, which can be seen if we look at the constructor as defined in the interface:

com.google.appengine.api.datastore.DatastoreService

public interface DatastoreService extends BaseDatastoreService {
    Entity get(Key var1) throws EntityNotFoundException;

Why would I need to catch the exception though? Why do I get the compile error?

Chris Halcrow
  • 28,994
  • 18
  • 176
  • 206
  • 3
    Is `EntityNotFoundException` a _checked_ exception? Checked exceptions _must_ be handled; that means either catching them or declaring the method can throw the exception. See https://stackoverflow.com/questions/6115896/java-checked-vs-unchecked-exception-explanation – Slaw Mar 29 '19 at 00:15
  • Thanks @Slaw, I think you should add that as an answer. I'm not sure why the OP is downvoted. The linked question you've provided is useful, but seems to assume that the developer already has a reasonable appreciation of checked vs unchecked exceptions. I think the OP is possibly in a good format that allows someone (like me) to derive that initial understanding. Can anyone comment on the downvote or suggest improvements to the OP? – Chris Halcrow Mar 29 '19 at 03:43

1 Answers1

2

Java has two different kinds of exceptions: checked and unchecked.

  • Checked Exceptions:

    • Any java.lang.Throwable that does not extend from java.lang.Error or java.lang.RuntimeException.
    • Must be explicitly handled where they can be thrown. Not doing so results in a compilation error. A checked exception is handled if it is caught in a try-catch block or if the containing method is declared to throws the checked exception.

  • Unchecked Exceptions:

    • Any instance of java.lang.Error or java.lang.RuntimeException.
    • Can be caught and handled, but doesn't need to be. Can also be used in the throws clause of a method signature but doing so is typically considered bad practice. If one wants to document the possibility of an unchecked exception being thrown by a method they should do so in the Javadoc, via @throws.

Based on the compilation error, I can only assume EntityNotFoundException is a checked exception and thus must be handled. For more information, see Java: checked vs unchecked exception explanation.

I agree that an empty catch block is smelly. At the very least, you should log the exception. If you end up doing the same thing for each possible exception, you could rewrite the try-catch like so:

try {
    /* Do stuff... */
} catch (EntityNotFoundException | IntantiationException | IllegalAccessException ex) {
    // log ex...
}

The above syntax requires Java 7+, I believe.

Slaw
  • 37,820
  • 8
  • 53
  • 80