Steve Stelting

author
+ Follow
since Feb 13, 2005
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Steve Stelting

Many thanks to YOU and Ernest, Dirk! I had a great time in the saloon, and I really appreciate all the great discussions throughout the week. My congrats to the winners... and if you'd like to continue "Roubst Java" related discussions, feel free to e-mail me.

Best wishes,
Steve Stelting
19 years ago
Hi Pradeep,

I'd tend to agree with Alex... the choice of checked vs. unchecked exceptions tends to be governed by the underlying assumptions upon which an API or framework is built. Depending on how rigorously and consistently those assumptions are enforced, it may be acceptable to rely entirely on unchecked exceptions, on checked exceptions, or on a mix of the two.

The rationale behind the checked exception is to communicate to a developer that there is a well-known error condition in an API call. Furthermore, I'd say that such an exception is most appropriate when it represents an error that the developer

  • is aware of
  • can do something about
  • has a choice for how to address the problem (usually)
  • could cause broader code failures if left unaddressed (often)


  • If these conditions are met, it seems reasonable to formally communicate the need to address the error. This would be particularly true (as Alex observed) when working between code layers, especially if the layers wwere independently developed and did NOT have a formal handling infrastructure in place.

    Unchecked exceptions, on the other hand, are useful in cases where the IS such an infrastructure in place to provide an acceptable "safety net" should such an error occur. They also tend to be useful when there are error conditions that have a suitable default recovery action that can be enforced in code should the developer elect to ignore the fault. I personally tend to think that one of the reasons unchecked exceptions are so popular today is due to the more sophisticated enterprise frameworks that have evolved over the lasst few years. If such frameworks are consistent and reasonable in how they handle such error conditions, they can offer a major boon to developers.

    The situations where the development community tends to get itself into trouble is when it uses handling alternatives as a reflex action, decoupled from thought and planning. There is a risk that developers will simply ignore unchecked exxceptions because they don't have to do anything about them. Likewise, there's a risk that developers will opt for the easy solution of a checked exception by "hiding" the source of the error in an empty catch block. Both stem from what I like to call reflex coding; both tend to substantially decrease code maintainability.

    Hope this helps; thanks very much for your question. On a totally unrelated thread, thanks for letting me put the table of contents for "Robust Java" on your blog, Alex.

    Best wishes,
    Steve
    19 years ago
    Hi Paul,

    Good question! There are indeed parts of "Robust Java" that I feel would be applicable to the broader work of developing robust enterprise software. Specifically, I've spent some effort elaborating good practices and key considerations in a few chapters in the book. It seems as though the following topics from the book all have more universal applicability:

  • best (and worst) practices for handling exceptions
  • exception handling and software design
  • exception handling in software architecture
  • design patterns and exception handling
  • testing
  • debugging


  • That said, all of the example code in the book is written in Java, and I don't specifically focus on other languages, technologies and frameworks. I suspect you'd have to do some filtering to gather more general recommendations for the .NET framework while reading the book.

    Hope this helps,
    Steve
    19 years ago
    Hi Pho Tek,

    I looked into the handling models for Struts, JSF and Spring while researching a presentation on Web tier exception handling earlier this year. My personal (admittedly biased) perspective was that each model was well planned, but based on slightly different framework handling philosophies.

    For instance, I got the impression that Craig wanted strike a balance in Struts... to create a handling framework that supported "plug-in" handling for some of the commoner errors, but was still open enough to support more sopisticated customization. That seems to mesh well with the more general goal of the framework - to provide a core programming model (MVC controller driven) that can be used out of the box, or customized to build more sophisticated solutions.

    In JSF on the other hand, the focus is very much on ease of programming and support for automated, IDE-driven efforts. As a result, its handling framework supports things like error page redirection and validation... standard MVC view-related error reporting that can be easily integrated into applications with minimal customization. For more detailed customization, I think developers would generally tend to fall back to the core Servlet/JSP handling structure, rather than modifying the JSF framework itself.

    It seems that Spring represents a sort of "reference implementation" of many of the best practices for lightweight enterprise development that Rob Johnson described in his popular Wrox press titles. From an exception handling point of view, this is reflected in the fact that the framework focuses to a large degree on RuntimeExceptions as the vehicle for communicating errors, which developers can handle (if desired) or which can be addressed by his enterprise infrastructure if left unhandled.

    As a student of architectures, I think there are lessons to be learned from each framework... they give us insight into a worldview of how to deal with errors in code. If developers are interested, I'll dig up the work I did earlier this year and post it to Javaranch (with permission of the Saloon keepers, of course!) when I get back to the U.S.

    Steve
    19 years ago
    Hi Stan,

    Actually, I've really enjoyed reading the discussions! It's neat to see so much brainpower concentrated on one Web site. I really wish I had worked with the forum for about 6 months before I wrote "Robust Java". I'm sure all of you would have quickly singled in on some of the finer points that took me months to express... such is the wisdom of teams!

    Steve
    19 years ago
    Hi Ko Ko Naing,

    Sorry for the late reply... it isn't really a chapter, but Amazon has also posted the preface of my book. You can find it at

    Amazon - Robust Java

    Hope this helps; feel free to email with any questions!

    Steve
    19 years ago
    Hi Pho Tek,

    I'm guessing you're referring to overriding the ThreadGroup method uncaughtException, right? If so, I do discuss it in chapter 4 (Exceptions and Threading) on pages 64-65. I didn't get a chance to talk about the newer feature in JDK5.0 (the Thread's method setUncaughtExceptionHandler) since Tiger had not yet been released when I went to press.

    The uncaughtException method can be a VERY effective way to build robust multithreaded code. And of course, it was formerly the only way a developer could address unchecked exceptions in a multithreaded environment. Of course, developers had to subclass the ThreadGroup to implement their own behavior... JDK5.0 has made it a lot easier to associate custom handling behavior with a specific thread by passing an implementation into the setter method mentionedd above.

    Best wishes,
    Steve
    19 years ago
    Hi Ko Ko Naing,

    There HAVE been some additions to the core language in Tiger that I hope to discuss someday... from an exception-al perspective. However, "Robust Java" covers only a few topics in JDK5.0 that I was certain would be in the Tiger release.

    I completed work on "Robust Java" a few months before Tiger was released. Of course, I couldn't resist putting some information about generics into my chapter on the I/O and Collection APIs. (Chapter 8)

    In the future, I hope to expand on that information, talk about the new threading APIs designed by Doug Lea... probably also branch out into enums and metadata. As Ali mentioned, I'd also like to expand the discussion about "classic" threads in Chapter 4 to include Thread.UncaughtExceptionHandler. It's a pretty significant feature for those who have to write multithreaded code, since it gives developers alternatives for dealing with exceptions that would previously have terminated a running thread.

    Hope this helps!
    Steve Stelting
    19 years ago
    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
    19 years ago
    Hi Louise,

    Based on a number of years spent in Java training, I'll fall back on the tried and true reply - "it depends".

    Ok, now on to a more useful, semi-serious answer!

    The runtime exception has had a somewhat contentious history in the Java language, as you probably know. Because the handling of errors tends to be strongly tied to developer philosophy, it's a topic of very... lively... debate.

    RuntimeException was originally used in the Java APIs to identify what could broadly be classified as "avoidable coding problems". In other words, most of the RuntimeException subclasses could be avoided entirely with a bit of coding. One example: developers can avoid the infamous NullPointerException if they check to see if the object reference is not null. Another: the IllegalArgumentException, which developers can avoid by prequalifying their input to method calls.

    As unchecked exceptions, RuntimeExceptions do not require developers to follow the process of handling or declaring them. The reason for this is fairly pragmatic: it is unrealistic to expect developers to address every possible failure scenario due to this type of problem. If you had to handle or declare every possible case where you could get a NullPointerException, your code would end up as a big try-catch block!

    As Java has expanded into the enterprise realm, the advent of architectural frameworks has encouraged the unchecked exceptions to be used in a somehwat new context. Specifically, unchecked exceptions tend to be used in enterprise servers to represent unexpected, "platform-related" errors. This trend manifests itself in J2EE as well as the more recent lightweight enterprise frameworks such as Rod Johnson's Spring. This is practical in part to the fact that the enterprise servers have a standardized handling infrastructure. Such frameworks have infrastructure to intercept and deal with this category or error, so developers can effectively leverage unchecked exceptions without danger of destabilizing an application.

    Which is more appropriate... the checked or the unchecked exception? I'd still tend to assert that "it depends" on the goals of a development team, combined with the degree to which they have a standardized handling strategy within their application environment. Used effectively, the unchecked exception can be an enormously useful addition to a team's handling repertoire. If misused, it can pose a major threat to application stability.

    Hopefully I've provided a detailed (and diplomatic) enough answer. Thanks very much for the question, Louise!
    19 years ago
    Thanks for the compliment! Incidentally, Amazon has a number of copies at substantial discount in their "used and new" section... apparently, some of their vendors are *very* well connected.

    Speaking of Amazon, they have a copy of the "Robust Java" preface on their site... for those ranchers who are interested, you can find it at
    Amazon - Robust Java
    19 years ago
    Hi Geoffrey,

    Yes, you raise a good point. The development team built the Java compiler to intercept and report any errors that could be detected during compile time. In the case of the instanceof operator, that means that any "impossible" tests will cause the compilation error you saw. Incidentally, we'd see the same thing if we tried to compile with an obviously incorrect class comparison. My earlier example will generate the same compiler error:




    We'll only get a clean compile if the object reference could possibly be of the class type indicated on the right... and then your code would work as advertized.
    19 years ago
    Hi Arijit,

    We talked about adding content for J2ME and Web Services in "Robust Java", but I didn't feel I had enough background to really do justice to the topics. I have done some additional work since publication, (I've developed talks for a few conferences) so if you'd like I can e-mail or post updates as I continue to do work. Let me know if that would be useful.

    Best wishes,
    Steve Stelting
    19 years ago
    Hi Vedhas,

    You're right that "Robust Java" covers more territory than exceptions. If I had to describe the book, I'd say that its main focus is how to use Java to write more robust application code.

    Part 1 describes the mechanics of handling exceptions, which basically focuses on the standard topics of exception handling. Part 2 talks about designing code to effectively use exceptions, and describes the error model in some common Java APIs (J2EE, JDBC and RMI to name a few). Part 3 branches out into architecture, patterns, testing and debugging... what I perceive as the broader work of using exceptions in the full lifecycle support of software.
    19 years ago
    Another potential problem with nested exceptions is the impact on bandwidth. There's an example in "Robust Java" where I propagated a simple SQLException forward to the Web tier of a J2EE application. In the natural process of nesting the base exception for transport, the exception picked up an additional 4kb of stack trace due to additional exceptions and code layers in the containers. Obviously, this could have serious performance implications if you had a frequently occuring application exception.

    While I agree that it's important to avoid coupling between parts of an enterprise, there may be some cases where exceptions are an appropriate way to communicate errors. A client will still have be tightly coupled to its server if it has to interpret and act upon an error. If a client must translate a string and act on the error, you haven't done yourself any favors by converting the exception in the first place.

    That said, you DO want to avoid exceptions that require a lot of analysis or interpretation from the client... for the same reasons expressed in "Bitter EJB".
    19 years ago