Require an improved Exception APIs
----------------------------------
Key: LANG-648
URL: https://issues.apache.org/jira/browse/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.
