• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

What is the rationale for making javax.persistence.PersistenceException a runtimeException?

 
Remko Strating
Ranch Hand
Posts: 893
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I used to work with java.sql.SQLException which is a checked exception.

Now I work with the persistence exception but this exception isn't checked. I've wrapped this exception now in a kind of subclass of the SQLException in which I've to catch this exception and make a good errormessage for the user. By using a runtime exception you can easily forget this.

Why is the javax.persistence.PersistenceException a runtime exception?

 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Remko,

The rationale isn't very good IMO. Here it is: http://www.onjava.com/pub/a/onjava/2003/11/19/exceptions.html. The argument is that run-time exceptions are more usable since you are not forced to catch them. The other rational is that you've messed up the application in unexpected ways. As the article mentions, checked exceptions are used to exceptions that you can be expected to handle.

Hope it helps,
Reza
 
Remko Strating
Ranch Hand
Posts: 893
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your reply and feedback.

Maybe I've get used to it. Now because I've made a subclass within SQLException I will catch it like an checked exception. This is because my error code works that way and for me is using JPA is a variant for using JDBC which I also use and I don't want to change the front, because of changing the back.

Mostly the user could do something changing values or phoning support. I just want the same page back and not showing the errorlog which makes the user affright.

The article states that sometimes a lot of exceptions are checked and are of no use if you can't change something over it. Sounds as a good principle. I will have a thought on that.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I dislike checked exceptions. Did you know that Java is the ONLY mainstream programming language that uses checked exceptions?

You can read what Anders Hejlsberg, the lead C# architect said in The Trouble with Checked Exceptions.
See also on C# Frequently Asked Questions : Why doesn't C# have checked exceptions?

However, I don't want to debate about checked exceptions in this topic. Suppose the checked exceptions are bad things (only suppose), it would be very hard for Sun to announce something like "Oh! We're sorry, but it seems that checked exceptions are bad, don't use them anymore" .

 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys,

I think checked exception are a valuable part of a type-safe API. However, overusing them is certainly not a good practice. In general, I agree with the article I posted. That being said, I do think that using unchecked exceptions for JPA is a border-line case. I personally would have opted to make the JPA exceptions checked, for the reasons outlined in the article.

Hope it helps,
Reza
 
Remko Strating
Ranch Hand
Posts: 893
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I personally don't know what to think. Normal SQL-statements throw a checked exception and JPA not, but a JPA exception shouldn't be a real system exception the user could enter wrong data which can be corrected afterwards. Maybe it's in the filosofie of JPA that this exceptions are checked before using JPA for updating and inserting by using the listener classes. But then you have also to throw a runtime exception.

The frustration of catching al kind of exception is also familiar for me. I try to catch them nicely, but time pressures make me sometimes just to use catch (Exception ex) en then log it and shows an error to the user. Mostly you don't do something else with it.
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Remko Strating wrote:I personally don't know what to think. Normal SQL-statements throw a checked exception and JPA not, but a JPA exception shouldn't be a real system exception the user could enter wrong data which can be corrected afterwards. Maybe it's in the filosofie of JPA that this exceptions are checked before using JPA for updating and inserting by using the listener classes. But then you have also to throw a runtime exception.

For me, this might be sort of an admission from Sun that using checked exception is not so good .

Remko Strating wrote:
The frustration of catching al kind of exception is also familiar for me. I try to catch them nicely, but time pressures make me sometimes just to use catch (Exception ex) en then log it and shows an error to the user. Mostly you don't do something else with it.

I believe this is one of the most important reason that why other programming languages don't have checked exceptions.
If catch then throw or just log, there is not point to catch it at all, just let global exception handler handle it.
But in Java we are *forced* to catch if it's a checked exception otherwise we cannot compile.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kengkaj Sathianpantarit wrote:For me, this might be sort of an admission from Sun that using checked exception is not so good .


I believe the primary driver here for JPA 1.0 was the Hibernate folks not using checked exceptions and believing strongly that they should not be used in JPA either. Checked exceptions are used extensively in other Java SE and Java EE APIs, including JDBC, Servlets, JMS, etc. I would be careful about making too many inferences that may or may not be accurate.

As to what other languages do, I don't see it as a very relevant metric. Java is, after all, more successful than these languages and that has been the case for a little while now. While there is certainly scope for learning from other languages, it should be done carefully. As I stated previously, checked exceptions are far more type safe and better documented in code. Just because checked exceptions might be inconvenient does not make them right for every case (or even a majority of cases). For one, unchecked exceptions have some of the same failings as COBOL or C error handling.

Hope it helps,
Reza
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reza Rahman wrote:
I believe the primary driver here for JPA 1.0 was the Hibernate folks not using checked exceptions and believing strongly that they should not be used in JPA either.

If checked exceptions are so good, why doesn't Hibernate use them?
If checked exceptions are so good, why don't other languages use them to be successful as Java?

I don't mean checked exceptions don't have any good attributes, actually the idea is good, but it's like we want to solve one problem but the way we do introduces another problems at the same level or worse, then what is the point to solve it?

It's not only about check exceptions, but in general I don't think we should solve a problem to get another problem.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think you missed the point - there isn't much value in arguing about what a particular API/product/language does or does not do.

I would certainly like to hear reasoning of where anyone might disagree with what is outlined about valid cases for checked exceptions as outlined by the article I posted (widely used as a Java best practice, including in Java SE/EE) or some of the specific reasons I have already cited (type safety, clear API contract, documentation, etc).

I don't see a problem with well-applied checked exceptions. I have personally seen them well applied in many enterprise Java solutions. I have also seen many failings for unchecked exceptions/errors in Java and elsewhere (some of which I have already mentioned as well).

As to the issue of trade-offs, that is a large part of computer science. The gray areas that require human judgement in measuring pros/cons of choices is what makes this art and not just a science :-).

Cheers,
Reza
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reza,
Reza Rahman wrote:I think you missed the point - there isn't much value in arguing about what a particular API/product/language does or does not do.

I think there is quite value to state that C# doesn't have checked exception because the designer team see big issues in checked exceptions: scalability and versionability.

Reza Rahman wrote:
I would certainly like to hear reasoning of where anyone might disagree with what is outlined about valid cases for checked exceptions as outlined by the article I posted (widely used as a Java best practice, including in Java SE/EE) or some of the specific reasons I have already cited (type safety, clear API contract, documentation, etc).

About type safety I think you mean compile-time checking, if I misunderstand please let me know.
When we develop software we have to test, don't we? And we have to test main paths, alternative paths, and exceptional paths. In case of unchecked we might forget to handle exceptions, but if we *forgot* it, is it really *needed* to be handled at all? If it's so important we'll not forget easily. Or if we really forgot, we will remember when test it, because the test will fail.

Checked exceptions don't force developer to handle exceptions *appropriately*, but they just force developer to write catch statement or declare throws statement in method header. Moreover, developers can (or tends to) write {} or just printStackTrace in catch body, you already know why, because developers are *forced* to catch, it's not their intention, many times they don't know how to handle exceptions appropriately or they don't want or don't think to handle at all.

This situation will not happen in case of unchecked exceptions, because developer aren't forced, if they handle unchecked exceptions, they handle them intentionally, and have idea how to handle them appropriately.

Regarding clear API contract, documentation, I'm not sure what you mean, we can document both checked and unchecked exceptions in JavaDoc.

Reza Rahman wrote:
I don't see a problem with well-applied checked exceptions. I have personally seen them well applied in many enterprise Java solutions. I have also seen many failings for unchecked exceptions/errors in Java and elsewhere (some of which I have already mentioned as well).

Two problems are scalability and versionability, even for "well-applied checked exceptions", anyway "well-applied" is so broad word, IMO if we use this word, we can design anything badly, and say that if use it well, there will not be a problem.
I don't mean checked exceptions are design badly, I hope you get my point.

I interest about failings for unchecked exceptions/errors, could you please to explain more?
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Kindly read the article for where checked exceptions fit best, I don't think it makes sense for me to repeat what I have already posted. It deals specifically and directly with some of what you are saying. It also includes a resources section that includes the resource you quoted along with a response from James Gosling. Here are a few simple examples that fit the best practices outlined in the article, hope it helps add clarity beyond the slightly theoretical/conceptual bend in the article:

1. Data input validation errors (examples would be user GUI input validation, range validation errors, format errors, parsing errors, etc).
2. Errors raised by business rules (e.g. action does not correspond with the current state of the system such as withdrawing money that isn't there, using expired credentials, etc).
3. Wrong usage of APIs (violations in work-flow, data insufficiently issues, etc).

In case of a well-designed API, the API designer should use checked exceptions to force the API user to handle error conditions that are expected to arise and can be handled properly only by the API user. Making these unchecked exceptions runs the risk of the API user not understanding the API correctly or ignoring errors that can happen frequently but not necessarily caught as a test case. One way to look at it is a type-safety issue. If the API requires a Date type, it makes no sense to accept a Object or String and do an internal cast. The API is such more clear and strict about it's intent by requiring the correct type to begin with. The same applies to checked exceptions. You are telling the API user beforehand that they must be aware of certain expected error conditions and handle them correctly as opposed to simply hoping for good behavior.

Valid cased for unchecked exceptions:
1. System errors caused by underlying resources (such as connectivity issues, resource allocation issues, etc).
2. Programming errors caused by the API designer (null pointer exceptions, array index out of bounds, etc).

These errors happen infrequently, are truly unexpected and the API user cannot be reasonably expected to handle them. In this case, you can give the API user a free pass not to handle these. This was the consensus for the JPA entity manager API. The JDBC expert group (and even the EJB expert group), have made the opposite judgment call and think the API user can and should handle errors arising from the API.

I simply don't see scalability and versioning vis-a-vis checked exceptions as real issues unless the checked exception facility is being abused (e.g. never using unchecked exceptions). For one, I have never come across such a case and apparently neither has James Gosling as he states in the interview in the resources section of the article I posted.

Hope that helps. That being said, I think we are approaching a point of diminishing returns here where it is best to simply agree to disagree? After all, even the article author recognizes some of the religious aspect of this very gray (and now old) debate originating mostly from .NET proponents.

Yet again, I am a little surprised as to why you are not thoroughly cognizant of these things already. The SCJP should have covered this? The Sun Java Tutorial certainly does: http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html. The title of this resource is "Unchecked Exceptions — The Controversy". I think the Sun best practices statement provides a very clear guideline and justification for the guideline.

Cheers,
Reza
 
Remko Strating
Ranch Hand
Posts: 893
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for your discussion and input.

I understand there could be a big debate over when to have and when not to have a checked exception.

At the moment I have to life with the inconsistency that sometimes communication with the database raises a checked exception (JDBC) and sometimes a runtime exception (JPA). I will try to use JPA in my applications for simplicity, but there will be a kind of migration process for it. For the time being I will catch the JPA exception and throw a kind of SQLException so that the other layers in my application will experience the same behaviour.



 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Remko,

Glad it helped. I was wondering if this was veering a little too far off topic myself.

The bottom line is that Java provides facilities for both checked and unchecked exceptions, with no particular bias in either direction and clear outlines for using both. It should be obvious that it is very difficult to argue that checked exceptions should never used, particularly with Java's historic focus on type-safety, rigorous API design and applicable best practices that have helped carry it so far, even despite fierce competition.

As I already said, the JPA case is very border-line, as is the JDBC case. The guidelines could be applied either way depending on ones particular inclination.

Cheers,
Reza
 
Hong Anderson
Ranch Hand
Posts: 1936
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Reza Rahman wrote:
Yet again, I am a little surprised as to why you are not thoroughly cognizant of these things already. The SCJP should have covered this? The Sun Java Tutorial certainly does: http://java.sun.com/docs/books/tutorial/essential/exceptions/runtime.html. The title of this resource is "Unchecked Exceptions — The Controversy". I think the Sun best practices statement provides a very clear guideline and justification for the guideline.

Reza, being a SCJP doesn't mean that I have to agree with everything that Java implements. And please, don't say like if anybody disagrees with Sun, then that person *is not thoroughly cognizant*.

Everybody can make mistake, and is not 100% right all the time. We can have different opinions, but we need to respect each other opinions as well.
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is no disrespect intended. Sorry if any was taken.

As I have said already, I am still unsure as to what exactly you disagree with. I would like to hear your arguments in terms of the counter-arguments that have already been presented by numerous independent Java experts including Joshua Bloch, not to mention Sun and James Gosling. Simply repeating points that have been countered already seems uninformed, at least to me.

Not sure why you would think I do not understand that anyone can make mistakes. I make them myself all the time :-). This is just not one of those times...

Cheers,
Reza
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic