Exception externalization

[andreister]

Hi there!

We are currently going to externalize exceptions in our application. It
is a server that has both thin and thick clients.

Generally, I see the three following possibilities for the server:
1. Request client locale within client calls and return
fully localized message in case of exception
2. Return not text but exception code so the client
will look up for the translated string in local bundles
3. Return not text but a key and parameters and then
the same as in 2.

Each one has its own pros and cons, namely:
1. Pros:
* do not need to update clients if
a new exception is introduced
or an exising one is updated
Cons:
* need to change dependent method
signatures to accept the locale param.
* forces the server to host resources for
all supported locales.

2. Pros:
* server does not care about client locales
* no need to change web services call
signatures and all dependent calls
to accept locale param
Cons:
* need to update thick clients if
a new message is introduced

3. Pros:
* the same as in 2 - BUT is a more flexible
since allows passing parameters so an error
message is more informative
Cons:
* the same as in 2.


I wonder if anybody could suggest any other approach or comment the
mentioned or point out some resources where I could find more info.

TIA,
Andrew

 

[Chris Uppal]

We are currently going to externalize exceptions in our application. It
is a server that has both thin and thick clients.

Doesn't support for thin clients mean that your server has to be fully locale
aware anyway ?

For thick clients, another possibility would be to create a new server request
which allowed clients to ask for an updated localisation bundle. For instance
if a client didn't recognise a given error code (or key string) then it would
ask the server for the localisation info for that key.

-- chris

 

[Robert Klemme]

Doesn't support for thin clients mean that your server has to be fully locale
aware anyway ?

For thick clients, another possibility would be to create a new server request
which allowed clients to ask for an updated localisation bundle. For instance
if a client didn't recognise a given error code (or key string) then it would
ask the server for the localisation info for that key.

What happens if that request fails? SCNR


robert

 

[andreister]

Doesn't support for thin clients mean that your server has to be fully locale

aware anyway ?

Yes, exactly

For thick clients, another possibility would be to create a new server request..

But what if error code hadn't been changed but the message itself had
been updated (e.g., to expect parameters that hadn't been there
before)?
I guess thick clients should ask for updated bundle on each connection.

--Andrew

 

[Chris Uppal]

(e-mail address removed) wrote:

[me:]

But what if error code hadn't been changed but the message itself had
been updated (e.g., to expect parameters that hadn't been there
before)?

I only intended that scenario as an example of the kinds of things you could
do.

I guess thick clients should ask for updated bundle on each connection.

Yes. Or ask whether the server had a newer bundle available, rather than
downloading it each time. More effort to program. Less data shunted around
the Net. Swings and roundabouts. Your choice ;-)

-- chris

 

[shypen42]

Hi Andrew,

Hi there!

We are currently going to externalize exceptions in our application. It
is a server that has both thin and thick clients.

....

There's something I'm not understanding...

Are you talking about "exceptions" as in "Java exceptions"?

If so, are the user of your thin client Java programmer? I don't
exactly see how Java's exception mechanism is related to the business
domain. I see how some exceptions may be related to the infrastructure
and realize that the user may understand that (eg "server doesn't
respond, try again later"), but I don't see the benefits in applying
l12n to a stack trace!?

Don't you simply want to turn an exception into an "error message"
understandable by the user (eg "network connection seems down") instead
of an Java exception stack trace?

I'm not familiar with externalizing exceptions, hence my question...

Talk to you soon,