commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Henri Yandell (JIRA)" <>
Subject [jira] Closed: (LANG-648) Require an improved Exception APIs
Date Sat, 01 Jan 2011 19:25:45 GMT


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

View raw message