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:
(this would of course mean that we'd have to add an additional constructor to the custom exception to accomodate the root cause exception)
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