Forum Stats

  • 3,816,603 Users
  • 2,259,212 Discussions


Unchecked Exceptions — The Controversy Rages On!?

User_65OMT Member Posts: 3 Green Ribbon

Hi Folks. I have an "observation" to make regarding the guidance on exceptions in the Java Tutorials (link below), and would be interested in the thoughts of others. I will keep this short and to the point. The page ends by stating..

"Here's the bottom line guideline: If a client can reasonably be expected to recover from an exception, make it a checked exception. If a client cannot do anything to recover from the exception, make it an unchecked exception."

I am struggling with this statement. Surely there is ALWAYS something a client can do to recover from any exception - be it checked or unchecked. For example if the client receives a runtime exception such as a NullPointerException because some service went down unexpectedly then the client could ultimately return a message like.. "The XYZ service is down. Please contact Operations blah blah.." We humans are capable of putting a man on the moon, so surely we can do something as simple as recovering from a runtime exception! Product managers and developers need to get together, and think outside the box to understand all the possible problems which could occur with their functionality at any time, and build in a means for recourse.


  • Billy Verreynne
    Billy Verreynne Software Engineer Member Posts: 28,805 Red Diamond

    There are 3 basic responses to an exception. Not Java issue or C/C++ issue or whatever programming language, but a fundamental software engineering principle.

    Add Meaning. Making the exception raised more meaningful by including for example what business rule has been violated.

    Take Action. Logging the exception, rolling back a db transaction, or taking whatever action required to prevent business logic inconsistencies - and then let the exception continue to be propagated up the call stack.

    Suppress. The exception does not impact the integrity of the business process, or violates the business transaction. The exception can be silently suppress, taken care of, and not be further propagated.

    In all other cases when one of these exceptions responses are not warranted, Propagate It! Enable the caller to examine the exception, and make its decision on how it needs to respond.

    If you want a nice error message in a pretty font to tell the end-user not to panic, that is done in the UI layer.

  • User_65OMT
    User_65OMT Member Posts: 3 Green Ribbon
    edited Mar 31, 2022 12:00PM

    Thank you, @Billy Verreynne for the valuable advice, and stating the principles. They are very relevant, and helpful to keep me on track!

    To add to the discussion, my thoughts are that if programmers find themselves having to add checked exceptions or when runtime exceptions are raised it should raise alarm bells. In both circumstances I feel the programmer should work with the owner of the functionality on an enhancement to handle the scenarios more transparently, and gracefully. I understand exceptions form part of the contract, but I often see examples where the client doesn't know how to handle them. The provider should assume minimum understanding by the client. eg..

    Example using exceptions..

    1. try { List<People> people = client.getPeople(personIDs) }
    2. catch ArrayOutOfBoundsException { Oh no! What does this mean? Client will have to ask the functional guys and API provider}

    Instead we can add method checkForInvalidPersonIds to the API..

    1. List<People> people
    2. List<InvalidPeopleIds> invalidPersonIds = client.getInvalidPersonIds(personIDs)
    3. if ( invalidPersonIds.isEmpty() )
    4. .....{Client gets it! These ids are invalid. Check with functional guys. Decision: display invalid ids to end user}
    5. else
    6. .....people = client.getPeople(personIDs)
    7. end if

    An alternative would be to convert the ArrayOutOfBoundsException to checked exception, InvalidPersonIDsException in getPeople(). However, to be equivalent, we would need save the list of invalid ids to this exception (yeuch!). Also, to retain transparency getPeople(personIDs) would need to be renamed getPeopleIfAllPersonIDsInListAreValid(personIDs) (yeuch!).

    These "all-in-one" methods, utilizing exceptions simply don't work for me. Exceptions are just resulting in obfuscation and FUD.

  • Billy Verreynne
    Billy Verreynne Software Engineer Member Posts: 28,805 Red Diamond

    This example falls into the Add Meaning category.

    A "technical exception" (such an array out of bounds exception, or NO_DATA_FOUND database error) has little meaning when the interface raising it is opaque. In which case adding functional meaning to it (such as "person not found") is required.

    The interface need to tell the caller why it cannot service the caller's request successfully. Not give the caller an internal technical processing exception, expecting the caller to understand how to deal with it, and whether the error can be corrected by the caller (e.g. invalid parameter value passed issue) or not (e.g. the opaque interface cannot call the mail/database server that's down).

    Just how this needs to be implemented, is language and design specific. No comments from me on Java. Not a language I like very much. But do your best to understand the software engineering fundamentals and adhere to these in whatever programming language used.

  • User_65OMT
    User_65OMT Member Posts: 3 Green Ribbon
    edited Apr 1, 2022 1:11PM

    Yes I agree, it's in the add meaning category. The spec needs to be simple, clear and unequivocal. pl/sql also has facility to RAISE exceptions to the caller, so the same applies to pl/sql. My conclusion (I think!) is that it's not good practise to make use of exceptions as a means to control which code path to follow. Preferably, a set of explicit and purpose built validation methods should be called at the decision points. This approach will prevent runtime/unchecked/system exceptions from being raised, AND eliminate any need for checked/user defined exceptions. Exceptions can be considered an anti-pattern as discussed here: Thanks