Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / General / May 2006

Tip: Looking for answers? Try searching our database.

Exception externalization

Thread view: 
andreister@gmail.com - 19 May 2006 11:20 GMT
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 - 19 May 2006 11:54 GMT
> 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 - 19 May 2006 12:35 GMT
>> We are currently going to externalize exceptions in our application. It
>> is a server that has both thin and thick clients.
[quoted text clipped - 6 lines]
> 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@gmail.com - 19 May 2006 13:07 GMT
> 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 - 19 May 2006 14:40 GMT
[me:]
> > 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 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@yahoo.fr - 19 May 2006 14:52 GMT
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,


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.