commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sangeeth Kumar S (JIRA)" <>
Subject [jira] Created: (LANG-648) Require an improved Exception APIs
Date Thu, 26 Aug 2010 16:16:53 GMT
Require an improved Exception APIs

                 Key: LANG-648
             Project: Commons Lang
          Issue Type: New Feature
          Components: lang.exception.*
            Reporter: Sangeeth Kumar S

Companies like Oracle, Microsoft who develop large software systems, maintain error codes
for each error state, their software may run into. For example, the error ORA-12514 ( related
to Oracle database) means the following

ORA-12514 Description: TNS:listener could not resolve SERVICE_NAME given in connect descriptor
Cause: The SERVICE_NAME in the CONNECT_DATA was not found in the listener's tables.
Action: Check to make sure that the SERVICE_NAME specified is correct. *Comment: This error
will be returned if the (database) service has not been registered with the listener; a database
instance that is part of this service may need to be started or configured properly.

The error codes helps both customers and the software companies to easily communicate about
the error scenes and quickly resolve the problems. Since error codes remain the same across
different languages, developers can quickly understand the problem, even if the customer had
given the problem details in a different language. Like error codes, there are several other
properties which can be associated to an exception. 

I see the following limitation in the existing Exception API in Java

#1 - The constructors of default exception classes take string as the message. To make the
code I18N compliant, additional code need to be written to fetch the message and pass it to
the constructor.

#2 - The standard exception objects carry only the formatted message. It does not assist the
calling routine to programmatically identify the cause.

#3 - The message carried by a standard exception object is preformatted; hence the calling
routine cannot translate the message to any other language at runtime.

#4 - The standard exception objects do not carry the severity of the error state.

#5 - The standard exception objects do not carry error code or any other property associated
to the actual error.

This new feature should assist resolving the above mentioned limitations.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message