Questions from Chapter 3 of Robust Java

[Chengwei Lee]

Hi Stephen,

I read through the sample chapter & had a some comments & few queries to seek your clarifications. In fact, I read it twice.

In page 36, third step for custom exceptions:

You issued a query to the database to check if the customer existed through the use of rs.next(). You then threw the custom exception if the resultset is non-empty.

I could've done this by simply attempting to insert the customer object & check the SQLException. Most databases would have sort of an error code to indicate the type of SQL error that had occured. I could have made use of this code in the stack trace to determine if it was an attempt to insert an existing object & hence throw the custom exception as well.

Between this 2 methods, since both involve making JDBC calls & if we're talking about J2EE applications with the database on a separate machine, which would result in a better performance? Or which, in your opinion, is the preferred method & why?

You'd subclassed the custom exception from the Exception class, would it be better to subclass it from SQLException instead? It is afterall an exception due to CRUD.

Also, you threw the custom exception like this:

throw new CustomerExistsException("Customer exists:" + c, c);

Since this is related to codes that you had in page 34-35, I felt that it would be easier to follow if you had included this constructor in the codes as well.

At the top third line,

The third and final step is to actually create the object...

I felt that it would be clearer to the reader if you'd prepended the word exception before object.

Also, you stated situations whereby exceptions could possibly occur. In the case of the customer example, I guess you're talking about internal problems with processing in the application. I just felt it would be better if you'd given more examples to the other 3 cases as well. For the experienced, perhaps it would be easy for them to associate the cases with their past experiences, but for the beginners that won't have much coding experiences, they might not have a clue to what the cases are.

In page 40, line 10, there is a glaring typo,
java.util.ReourceBundle should have been java.util.ResourceBundle instead.

For the codes representing language & country, are they case-sensitive?

I like your parting shot in the chapter very much. To me, it makes perfect sense to avoid throwing an exception as much as possible. We should design the program carefully to avoid excessive use of exceptions.

It is a rather short chapter for an advanced topic. But it is an important topic since most of the time, developers would need to create custom exceptions specific to their applications.

Would be good if it could be packed with more examples.

Would shamelessly ask more questions when I can think of. Thanks!
[ March 09, 2005: Message edited by: Chengwei Lee ]

[Avi Abrami]

Chengwei,
I hope that you (and Stephen) won't mind if I reply to some of the issues raised in your question.

Most databases would have sort of an error code to indicate the type of SQL error that had occured.

For the example used, the error you are referring to would only occur if there was a constraint on the table that only allowed unique values for the combination of first name and last name. So, strictly speaking, your assumption may not always be correct.

In any case, example code in books is designed to illustrate a concept. And sometimes it is more difficult to illustrate a concept using production-quality code, since production-quality code involves other factors (like performance, as you mentioned). So in order to keep things clear and simple, example code should only concentrate on the concept it is trying to illustrate.

That said, I like Stephen's writing style. I think it is excellent. If you aim for a wide audience, then obviously you need to cater for the lowest common denominator. In other words, the book is obviously written for people with little experience in the world of exception handling in java, but still entertaining enough for those who are not novices (like me )

would it be better to subclass ... SQLException instead?

Only if you wanted to inherit something from "SQLException" (like the database error code?).

For the codes representing language & country, are they case-sensitive?

Although error messages and internationalization overlap -- as Stephen indicates in chapter 3, I feel your question is purely related to I18N. Allow me to make you aware of the following Web site:
[One of many on the subject.]

http://www.joconner.com/javai18n/

Good Luck,
Avi.
[ March 10, 2005: Message edited by: Avi Abrami ]

[Steve Stelting]

Hi Chengwei and Avi,

Thanks very much to both of you for taking the time to read the chapter! Thanks also for both of your feedback... I'll do my best to provide clear, thoughtful responses to your questions, Chengwei.

1. Custom exceptions (p. 36, JDBC code example)

You're absolutely right - it would be OK to try a SQL INSERT and handle the resulting SQLException, subject to the constraint Avi mentioned. My motivation for writing the code this way was to show a basic example of how to throw a custom exception. Since I cover JDBC in greater detail in chapter 9, I tried to avoid a "deep" discussion about the uses and challenges of the API until that chapter.

You're correct that the INSERT-handle strategy would almost certainly be the more performant alternative. Of course, we might well want to perform some additional exception analysis in that case. The SQLException is unfortunately used to communicate almost every problem related to database or driver use.* As a result, we might decide that it's important to evaluate the SQLException and take action based on the type of error. Since I wanted to avoid such detailed discussions until a bit later in the book, I stuck with what I felt to be a more straightforward scenario.

*With the exception of SQLWarning, BatchUpdateException and DataTruncation, of course. These exceptions occur in very specific, well-defined situations... and the SQLException is thrown for everything else.


2. Custom exception: Subclassing Exception

Should we subclass SQLException or the Exception class? I'd tend to say the answer depends on a development team's perspective about how the error should be used and interpreted. I'd tend to say there are two possible ways to present the exception to a consumer:

as a database problem

as a business error

In this example, I wanted to emphasize the interpretation of the error condition in a business context. If the error could be interpreted and acted upon in the context of database handling, it might also be appropriate to base the exception on SQLException, or to associate a root cause exception as shown below:

 
    public void insertCustomer(Customer c) throws CustomerExistsException{
        String insertSql = "INSERT INTO Customer VALUES(?, ?)";
        try{
            Connection conn = dbmsConnectionFactory.getConnection();
            PreparedStatement insStmt = conn.prepareStatement(insertSql);
            insStmt.setString(1, c.getFirstName());
            insStmt.setString(2, c.getLastName());
            int status = insStmt.executeUpdate();
        }
        catch (SQLException exc){
            throw new CustomerExistsException("There has been a problem with with the DBMS customer insert", exc);
        }
    }

(this would of course mean that we'd have to add an additional constructor to the custom exception to accomodate the root cause exception)

 
    public CustomerExistsException(String message, Throwable rootCause){
        super(message, rootCause);
    }

3. Custom exception: Constructor CustomerExistsException(String m, Customer c)

You're absolutely right. I had intended to include the additional constructor in the code for the custom exception... and it is in the source code for the examples. The example IS much clearer if the constructor is included in the file, isn't it?


4. Throwing exceptions (p. 36)

I see your point about providing additional examples for beginners... that's especially appropriate in this case, since the chapter was really written with beginner to intermediate programmers in mind.


5. Typo for ResourceBundle (p. 40)

Yeah, you got me. My proofreader missed the spelling in one of my paragraphs. Guess I owe you a drink for finding that.


6. Locale codes for country and region

The locale codes are defined by a pair of specifications, ISO-639 and ISO-3166. The specifications define the country code as lowercase and the region as uppercase, and the Java code follows the convention and therefore enforces case sensitivity. As an interesting side note, the source code was originally developed by Taligent. Hopefully, this information will help someone to win a "Java trivia" contest someday!


Other thoughts: I agree that there's a lot more that a person could write on the fundamentals. I purposely tried to make part 1 concise (it's about 80 pages long) to ensure that beginning Java developers could read it in a short time and get the key points necessary to help them with the mechanics of exception handling.

Depending on whether Prentice OK's "Robust Java" for a second edition, I'd be most interested about what folks in the developer community feel would be useful additions. I had originally planned to write a 250 page book, but it turned into 400 pages when all was said and done! If there's more that developers would like to see, I'd be quite happy to post additional information... and we could see where it all goes. It's through such efforts that our profession grows and improves.

Once again, thanks for your questions and your feedback! Thanks also for your input, Avi. I'm glad to hear that the chapter strikes a reasonable balance for more senior software developers! To be honest, I had wondered if higher-level developers tend to make a beeline for part 2 of the book. I feel like there's some fairly innovative material farther back in the book.

Best wishes,
Steve

[Chengwei Lee]

Thank you Avi & Steve for your explanations.

Actually I won't mind reading a thicker chapter 3. In fact, I look forward to it.