Exceptions

[Gerrie Myburg [ MTN - Innovation Centre ]]

I am currently looking at exceptions and the way they are used in ofbiz.
More than one issue needs to be resolved. As a first iteration I am
looking at:

1. Externalizing string used in exception constructors into existing
resource files
2. Make strings used in exception reporting context sensitive. i.e.
different messages for different classes of users.

The one way I can address the above points are to do the following:

In GeneralException create 2 new methods

    public GeneralException(final String mgs, final String[] keys)
    public GeneralException(final String msg, final String[] keys, final
Throwable nested)

Keys are used to refer to the externalized strings in the resource file.
The methods then construct the exception message from the external
resource files. If the external resources are not found then mgs is
used. These two constructors are then made available in all the child
classes.

All exception in the system should now be changed to include the
externalized string keys. There are something like 2500 exceptions to be
changed.

I will also have to add a method to UtilProperties.

getMessageTranslateParams("resource", "Resource key", new Object[]
{"parameter key 1"..."parameter key 2"}, locale);

The normal getMessage using Object[] as parameter does not translate the
parameters and uses the object string directly in the resource string.
This is not desirable when message translation is done. From a
translation point of view the parameters also needs to be taken from the
resource file and not used as is.

The advantage to this approach is that the code impact is minimal; it is
a lot of work but not complex and risky.

I am aware that exceptions are used for reporting a variety of errors
ranging from data base exceptions to data validation problems.

The biggest problem that I cannot resolve is how to correlate an
internal error to user input. To illustrate: the user gets confronted
with an error message that is understood but the user has no idea of
what he did to trigger the error. This type of problem happens when user
input validation is either incomplete or non existent and the generated
error does not refer to the user input. In this case externalizing
exception strings will not help at all. I propose that this issue looked
at as a separate project.

[Gerrie Myburg [ MTN - Innovation Centre ]]

In reference to the work I am doing to externalize all exception literal
strings into property files.

I need to know if the exception property file should be appended to the
<module>UI labels property file or can I create one exception.property
file that contains all the exception strings?

Reason I ask is that I wrote an number of awk scripts that does the
actual data extraction and code editing for me. So getting the data out
and changing the code is turning out to be relatively simple.

[David E Jones-2]

They really do need to be separated by component so that as much as  
possible each component has and uses its own resources. Sharing  
between components, or using resources from other components, is fine  
when necessary or when the same thing is really used by multiple  
components, but putting everything in one big blog makes it somewhat  
cumbersome to manage/maintain.

-David


On Sep 27, 2006, at 1:02 PM, Gerrie Myburg [ MTN - Innovation  
Centre ] wrote:

> In reference to the work I am doing to externalize all exception  
> literal
> strings into property files.
>
> I need to know if the exception property file should be appended to  
> the
> <module>UI labels property file or can I create one exception.property
> file that contains all the exception strings?
>
> Reason I ask is that I wrote an number of awk scripts that does the
> actual data extraction and code editing for me. So getting the data  
> out
> and changing the code is turning out to be relatively simple.
>
>