Is a method in a JPA entity allowed to throw an Exception?

Question

I have a problem with an @Entity I am trying to create. The problem arises when trying to test the class in Eclipse using an OpenJPA implementation (I have not tried others so not sure if it might work with them).

My test case is simple enough in that it creates an EntityManagerFactory (which automatically finds the persistence.xml on my classpath) and then it tries to create an EntityManager from the factory. This is when I get hit with a very ambiguous 'PersistenceException: null' error.

The Entity with the problem is the following LogError class. I have stripped it down to the bare minimum and it still throws an error.

@Entity
@Table(name = "T_LOG_ERROR")
public class LogError {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
private Long ID;

private String ERROR;

protected LogError() {}

public String getErrorName() throws FieldNullException {
    if (this.ERROR == null)
        throw new FieldNullException("error was null", null);
    return this.ERROR;
}

public setError(SystemError error) {
    this.ERROR = error.getClass().getCanonicalName();
}

}

I have discovered that the problem seems to lie with throwing an exception within the getErrorName() method. You see, if I was to comment out the first two lines of the method like so:

public String getErrorName() throws FieldNullException {
    //if (this.ERROR == null)
    //  throw new FieldNullException("caughtException was null", null);
    return this.ERROR;
}

then the error disappears. Just to clarify, the FieldNullException is my own custom made exception, however it does not make a difference as I have tried with standard java exceptions such as NullPointerException and the error is the same.

So my question is, is it illegal to throw exceptions with methods of an Entity class?

And also why do I get an error?

Here is my tester method:

@Test
public final void test() {
    emf = Persistence.createEntityManagerFactory("testPersistenceUnit");
    emf.createEntityManager(); // problem arises here!
}

I have attached the stack trace below:

<openjpa-2.2.0-r422266:1244990 fatal general error> org.apache.openjpa.persistence.PersistenceException: null
at org.apache.openjpa.enhance.ClassRedefiner.redefineClasses(ClassRedefiner.java:96)
at org.apache.openjpa.enhance.ManagedClassSubclasser.prepareUnenhancedClasses(ManagedClassSubclasser.java:176)
at org.apache.openjpa.kernel.AbstractBrokerFactory.loadPersistentTypes(AbstractBrokerFactory.java:314)
at org.apache.openjpa.kernel.AbstractBrokerFactory.initializeBroker(AbstractBrokerFactory.java:238)
at org.apache.openjpa.kernel.AbstractBrokerFactory.newBroker(AbstractBrokerFactory.java:212)
at org.apache.openjpa.kernel.DelegatingBrokerFactory.newBroker(DelegatingBrokerFactory.java:156)
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:227)
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:154)
at org.apache.openjpa.persistence.EntityManagerFactoryImpl.createEntityManager(EntityManagerFactoryImpl.java:60)
at 
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.openjpa.enhance.ClassRedefiner.redefineClasses(ClassRedefiner.java:85)
... 34 more
Caused by: java.lang.VerifyError
at sun.instrument.InstrumentationImpl.retransformClasses0(Native Method)
at sun.instrument.InstrumentationImpl.retransformClasses(InstrumentationImpl.java:144)
... 39 more

Why I want to throw the exception anyway

For me, throwing a FieldNullException on each getter method that represents a column that NULL is allowed, forces the user of these getter methods to take appropriate action when needing the values of these getters.

So for example:

// At some point this object is created:
LogError logError = new LogError();
logError.setError(new SystemError());

// Some point later, someone wants to retreive the error name from this object 
// and pull only the first 10 letters for display
try {
    return logError.getErrorName().substring(0,10); // Safely perform substring
} catch (FieldNullExcepion) {
    return "";
}

If my getter did not have a 'throws FieldNullException' then it potentially allows a user of the getter to perform an action on a null object:

// If getErrorName() returns null, then this will throw NullPointerException!
return logError.getErrorName().substring(0,10)

To avoid this the user can obviously check if the returned value from the getter is null before performing anything else and there is nothing wrong with that. The benefit of my way, is simply to say 'hey, this field may contain null so take appropriate action'.

And an Entity can have many fields, so attaching 'throws NullFieldException' on the getters that allow null, will conveniently signal to the caller which exact fields may be null and thus take alternative action on them. Thus not having to try and remember which may be null or pulling up your entity to check for your @NotNull annotations etc.

Write once and let it remind you ;)

I do not use these methods for validation and I don't see how it is business logic. It is completely to do with the characteristic of the underlying database field.

I think the problem lies in the way, the JPA provider tries to find out details about the classes: it executes the get/set method on startup and that invokation throws an exception as the entity/class is not completely instantiated. In your case, you either have to encapsulate the error class in some other class to decouple entity and model or you have to declare the column as non-nullable, so any save with an error = null will result in an exception. — Dominik Sandjaja, Feb 05 '13 at 13:28
What's this class `com.zero64.utl.server.log.service.LogServicePackageTest`? Can you provide the code for this? Did you write such class? Do you get the error while compiling and are you using Maven? In this case, try compiling with `-Dmaven.test.skip=true` property to skip tests — ThanksForAllTheFish, Feb 05 '13 at 13:30
@DaDaDom I'm not entirely sure what you mean, but I have tried annotating Column(nullable=false) and also tried NotNull (vaidation) yet the problem remains. Mardavi I attatched the test code, there is nothing to it really. I do not use maven. — Milo Jasper, Feb 05 '13 at 13:44

DataNucleus · Answer 1 · 2013-02-05T14:21:05.377

2

No its not illegal, and some JPA implementations (e.g DataNucleus JPA) don't go about calling getters (except when using property access, which you aren't), those are for the developer to call. It also isn't for persistence specifications to impose anything on a developer; there is no "right" way to use a language and design your classes so if you want to have model classes with behaviour then fine, and they should be persistable in the same way

edited Feb 05 '13 at 14:21

answered Feb 05 '13 at 13:43

DataNucleus

15,497
3
32
37

Thanks for your input! I agree that we should be free to design our entities as we wish without too many restrictions. – Milo Jasper Feb 05 '13 at 22:02

Rick · Accepted Answer · 2013-02-18T19:01:55.397

1

A first place to start would be to enhance your Entities at build time, or use the -javaagent! Don't use openjpa.RuntimeUnenhancedClasses as there are lots of known bugs with that feature.

edited Feb 18 '13 at 19:01

answered Feb 05 '13 at 21:25

Rick

3,830
1
18
16

This is exactly what the problem was. I was not enhancing my classes and it seems runtime enhancement just didn't like exception throwing within methods. Enhancing the classes at build time threw no such error and my testes ran fine! Thanks a lot! – Milo Jasper Feb 18 '13 at 15:40

Óscar López · Answer 3 · 2013-02-05T14:21:38.370

0

Even though it can be done, it doesn't mean you should. Throwing exceptions in an entity seems like a bad coding smell to me. Entities should not have any business logic, so exception handling in there would be out of place, anyway.

Java EE design patterns encourage a procedural way of thinking, applying OO concepts at the entity level is OK for modeling data (inheritance, polymorphism, etc.) but not behavior - that is to say, validation logic, business logic etc. should reside outside entities and exist only in business classes. The only business logic that makes sense to put in an entity, would be the named queries that apply to it.

edited Feb 05 '13 at 14:21

answered Feb 05 '13 at 13:38

Óscar López

232,561
37
312
386

1

Actually, many would argue that such an entity is anaemic, which is to say an anti-pattern. According to OO an object has both properties and methods. . traditionally since an object would be emitted from a session factory, it would be hard to inject collaborators, but frameworks like Spring @Configurable or Roo, etc work around this now. . . Next question is what to part into the service layer vs in the object. . Service layer is use-case specific and orchestrates process, while entity methods are reusable and relate to the properties. – Jasper Blues Feb 05 '13 at 13:43
Personally for me, it is a convenient way to remind me which fields of my entities are allowed to be null (as per my database table spec) so as to take appropriate action if I try to get the field and it is null, rather than throwing a NullPointerException when I try to use the null returned field. – Milo Jasper Feb 05 '13 at 13:48
Entities, according to the strictest interpretation of Java EE patterns, should only contain data - business logic should reside elsewhere, for instance in EJBs. Nobody said that Java EE promotes a nice, clean OO programming model, on the contrary, it encourages a procedural way of thinking. – Óscar López Feb 05 '13 at 13:50
@MiloJasper that's not the way to go. You should use annotations or attributes on each field to mark those that can be null, and forget about performing that kind of validations on this tier of the application. If you need to validate this before manipulating the entity, do so in the presentation or in the controller, not in the data model – Óscar López Feb 05 '13 at 13:53
@ÓscarLópez Thanks for all your input. I should clarify that I don't use these methods for validation and I don't see how it is business logic if it is a characteristic of the underlying field in the database. I have edited my post to explain why I would use it. Please see above. – Milo Jasper Feb 05 '13 at 22:00

Is a method in a JPA entity allowed to throw an Exception?

3 Answers3

Linked