Skip to main content

Another plea for better error messages

8 replies [Last post]
Joined: 2003-06-13

I just wasted two hours trying to debug a simple EJB3 program. Here is the error message that I got:

[java] Caused by: Exception [TOPLINK-7154] (Oracle TopLink Essentials - 10g release 4 ( (Build 051205Dev)): oracle.toplink.essentials.exceptions.ValidationException
[java] Exception Description: The attribute [choices] in entity class [class elvis.entity.Question] has a mappedBy value of [question] which does not exist in its owning entity class [class elvis.entity.Choice]. If the owning entity class is an @EmbeddableSuperclass, this is invalid, and your attribute should reference the correct subclass.

I double-checked everything and even ran the example at for comparison (which worked correctly). Finally, I realized that I had made a really stupid mistake.

I forgot the @Entity declaration in the Choice class.

I know that was stupid, but real programmers make stupid mistakes. Wouldn't it be easy to check for this mistake in the ORM layer and give a better error message?



Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2005-03-30

> ... My hunch is
> that there isn't even an infrastructure to it. For
> example, when a TopLink or JSF implementor senses a
> problem, is there an API for reporting to the
> deployer "Look into line x of this file--it seems to
> have caused an error"?

Actually there is an infrastructure to do this in Glassfish. Log messages can contain diagnostic causes and diagnostic checks. These lists of things that potentially caused the problem and ways to check/fix the issue are meant for this exact purpose. Perhaps these messages identified in this thread can use this feature (they currently don't, unfortunately).

The Admin GUI's Log Viewer is capable of displaying the diagnostic information on the detail page of the error... which, although this is a great feature, brings us to your 2nd point: developers don't want to hunt for the problem. It should be presented to them. In the JSF case, this means the ViewTag should produce output that states it can't render the page vs. an exception.

Thanks for posting these issues, this will help improve Glassfish.



Joined: 2003-06-10

I have another comment on that:

Java EE 5 is all about Ease of Development.
This does not stop at the new annotations or default values proposed in the spec. It has to go all the way to the runtime, to error messages, to better tools support, to self correction in the runtime and improved diagnosability...

The new features at the spec level are just an enabler for EOD, but it is clear from your feedback (I love it!) that many things need to happen also at the runtime level and the Tools level.
So I am with you there. Capturing current behaviour in bug reports is the best course of action.


PS: The analogy I keep saying to developers I talk to is:
Imagine you are driving your car, and suddenly, a RunTime Exception stack trace pops up in your dashboard...What would you think about the car maker? Maybe in the early 1900s, but not now anymore!

Joined: 2003-08-24

I second this motion. Tbe biggest problem I've had with Hibernate is how poorly it validates configuration problems. You end up wasting hours or days trying to figure out why something isn't working because there is no obvious indication of what is actually wrong. In the world of ORM and XML files, it is vital to provide a full configuration validation.

I hope GlassFish won't end up with the same problems.

Joined: 2003-09-03

I have to say that I agree with both of you. There is a lot of poor error messages out there.

That is usually because the person writing the error message is "in the code", and has trouble getting their head back up to the user level.

That is where the two of you can help/contribute....

Please consider creating a few sample persistence modules with a single simple error along with the text of the error message that you think will help the user resolve the issue. Send this bundle to the folks that are working on the persistence "area".

Such a "test suite" would be a valuable contribution to the development of Glassfish.

Joined: 2003-06-13

Indeed, a test suite of typical beginner's messages would be a good thing. (A couple of days ago, I wasted two hours with inscrutable stack traces because I kept pointing my browser to localhost:8080/index.jsp instead of localhost:8080/index.faces. Surely I wasn't the first and only idiot who ever did this...)

But there is a more sinister issue. The error reporting in GlassFish (and, I am sure, Hibernate) is fundamentally deficient.

The GlassFish (and Hibernate and ... and ...) developers think they are doing a great and wonderful thing if they launch an exception or write a log message.

They are not.

Imagine for a minute if the Java compiler worked like that. Every time you have a syntax error, the compiler would simply die with an exception, or it would deposit a logging message into a log file.

It would take you forever to get your programs compiled.

Compiler writers know that errors are to be expected. [b]Human errors are normal things, and not exceptions.[/b] Compiler writers make an effort to report errors that humans can understand, and to keep going to find more errors.

There is absolutely no commitment to doing that in GlassFish (and many other app servers). My hunch is that there isn't even an infrastructure to it. For example, when a TopLink or JSF implementor senses a problem, is there an API for reporting to the deployer "Look into line x of this file--it seems to have caused an error"?

Unfortunately, with server-side Java, [b]programming is no fun[/b] but, for most hours of the day, the mind-numbing drudgery of looking at stack traces and logs.

I think this is a very sad state of affairs, and it drives people to consider technologies like "Ruby on Rails". When I look at the RoR feature list, most items leave me cold, but one item resonates with me very much: "Brings the fun back into programming".


Joined: 2003-09-03


While I completely disagree with your statement, "There is absolutely no commitment to doing that (provide useful error messages) in GlassFish", I can also offer a solution.

Get involved in solving the problem.

You have voiced your concerns about this issue. Now do something about them.

File bugs that have reproducable test cases.

Take up the challenge that I gave you earlier.

As Bigweld says, "See a need, fill a need".


Joined: 2003-06-13

I'd be glad to do that. Where would I submit them to, and how would I check the progress?



Joined: 2003-09-03

The GlassFish project uses the issue tracker.

The URL for the glassfish tracker is:

There is some help for the issue tracker here:

One very important thing to remember is that you must be logged in to file issues. If you are posting in the discussion forum area, you are already logged in.

You may have noticed that pramodgo openned issue 127 based on one of your forum postings... You may want to add more details to the issue or attach a small sample which demonstrates the issue.