[LANG-648] Require an improved Exception APIs

• Type: New Feature
• Status: Closed
• Priority: Major
• Resolution: Duplicate
• Fix Version/s: 3.0
• Component/s: lang.exception.*
• Assignee: Unassigned
• Reporter: Sangeeth Kumar S
• Created: 26/Aug/10 16:14
• Updated: 01/Jan/11 19:25
• Resolved: 01/Jan/11 19:25

Description

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.

Issue Links

• is related to: LANG-497 Addition of ContextedException and ContextedRuntimeException