[NAS-1729] Update exception handling strategy Created: 09/Jun/09  Updated: 16/Jun/11

Status: Open
Project: NetarchiveSuite
Component/s: Common
Affects Version/s: 3.8
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: Nicolas Giraud (Inactive) Assignee: Unassigned
Resolution: Unresolved  
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Organization:
General

 Description   

Currently the very few existing application exceptions inherit from dk.netarkivet.common.exceptions.NetarkivetException which itself extend RuntimeException.
In my experience I have observed that is is generally a good programming practice to have a more evolved exception handling:

  • first I would not use RuntimeExceptions unless we are sure the error is unrecoverable and even so I never use RuntimeExceptions in any production quality code for the reasons listed below
  • provide a simple API for application exception that allows:
  • distinction between application errors (i.e. errors that we know might happen during processing and that we want to precisely identify as such and potentially try recovering from) and unexpected errors (anything else)
  • uniquely identify an application error
  • provide additional information than stack trace
  • automatically log any application error with support for internationalization
  • associate a criticity level to an application error (i.e. is it worth continuing running the application when error X happens or is it recoverable)
    I am not especially fond of very complex exception handling but the simple fact of being able to precisely track the nature of an error and be sure it is logged without cluttering the code with catch/log statements is something I find crucial and do in nearly any Java program I write even the simplest ones.
    I'll be happy to discuss this when the opportunity arises.

 Comments   
Comment by Mikis Seth Sørensen (Inactive) [ 16/Jun/11 ]

Ohhh, and of course it should be possible to define new exception types in all modules.

Comment by Mikis Seth Sørensen (Inactive) [ 16/Jun/11 ]

We recently discussed this and agreed that the Exception handling strategy used in the Bit Repository project. Both Mikis and Jonas (and Kåre, forme NAS guy) participates in this project, where the exception strategy is based on the NAS strategy with modifications for the shortcomes found here.

Comparing the concerns listen in this issue and the Bit Repository strategy:

  • Runtime exceptions may be used, but the concept of fail barriers should prevent uncheck exception from propagating to the application uncontrolled.
  • The distinction between application errors(contingencies) and unexpected errors (faults) are defined in both places.
  • In both places application errors(contingencies) should be have a type hierarchy making it possible for the exception catcher to distinguish between different error situations.
  • In both places documentation of the exception should be enforced.
  • SB and KB disagrees with the idea of adding support for support for internationalization in exception. This would cost a lot of time and add additional complexity to the error handling code, which in the last thing we want. We consider the technical staff the main audience for the exception information. Exposing exception information (in a general and formalized way) for non-english and perhaps nontechnical NAS users is considered far outside of scope by KB and SB.
  • The criticality of exceptions should be determined by the catcher of the exception based on type and should not be a responsibility of the exception thrower. Choosing whether to to crash or continue a component should be handled in the fault barriers.

Note that the idea of clearly defined fault barriers are crucial to the idea of using unchecked exceptions. A natural place to implement fault barriers are when creating new threads (not the only place). NAS could certainly use a consolidation in this area.

Comment by Mikis Seth Sørensen (Inactive) [ 17/Nov/09 ]

svc - svc@kb.dk - 06/10/2009 10:17:14
The reason for our use of Unchecked exceptions are explained in our coding guidelines:
http://netarchive.dk/suite/Guidelines/Coding_Guideline#head-ff7bc92c000389a9865fda2e63098e051a05b036

svc - svc@kb.dk - 11/30/2009 16:13:31
This was discussed on the last internal netarkivet developer meeting and it was decided that Nicolas Giraud as the one in the developergroup with the most interest interest in this issue should start a thread on this on the netarchivesuite developer mailinglist.

Generated at Thu Apr 18 10:54:38 CEST 2024 using Jira 9.4.15#940015-sha1:bdaa9cbecfb6791ea579749728cab771f0dfe90b.