[
https://issues.apache.org/jira/browse/LANG-648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Yandell closed LANG-648.
------------------------------
Resolution: Duplicate
Fix Version/s: 3.0
Comparing LANG-497 to this, I think the new ContextedExceptions assist in #2,
#3, #4 and #5. I18N is still outside of its scope.
Resolving as Duplicate as I don't see any obvious i18n changes in the exception
space.
> 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
> Fix For: 3.0
>
>
> 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.
