[jira] Closed: (LANG-648) Require an improved Exception APIs

["Henri Yandell (JIRA)" <ji...@apache.org>]

     [ 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.