commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: [all] exceptions and localization
Date Mon, 29 Jan 2007 09:27:59 GMT
Selon Jörg Schaible <>:

> you cannot build a common
> library with meaningful exception messages (or log entries) that really makes
> sense for a user in the context of an application that builds on it.

This is often true, in this case the exception is caught by some middle layer
and either replaced by or wrapped within another one, regardless of the message
being localized or not. This decision depends on the understanding of the
exception at the middle layer. In the advertised case, the layer really knew the
meaning of this error at its own level despite it has been triggered at a lower
level, so it knew how to build a better message (again, regardless of the
localization). There are cases, however, when the middle layer has no hint about
what meaningful information to add, despite it knows a larger or more abstract
context, so it better let the exception go as is without even catching it.

As we build reusable components that will be embedded in other components, we
cannot rely on a single use case of our code. It has to be as versatile as
possible to meet many requirements. Some users will rewrite every message,
others will simply display what was built at low level, both are legitimate use.

> We have some global players as customers and they all have very specific
> needs for logging and error messages (e.g. every logged entry has to be
> defined and must have an ID and has fields with fixed length, exceptions have
> to be reported as part of the return value of service calls again with
> special identifiers and filled-in parameter values for the error).

I know about those needs and they are well addressed by exceptions that can be
caught and modified at will, regardless of the localization status.

> My bottom line: If you build an application, you have to do localization (of
> exception and logging) at the application layer, because only there you can
> give the user a context, that is really useful.

I think error messages belong to the information set that *may* be propagated to
upper layers according to upper layers design choices. If upper layer is
localized, lower layers should also be localized.

> This implies catching
> exceptions from libraries and wrapping them with your own and it implies
> also, that you should have access to the basic parts of the exception (e.g.
> the file name) easily i.e. usign the exeption's API. This part can be
> provided by a common lib (and the JDK fails here often enough badly), but it
> cannot serve the requirements of an application it has no knowledge of.

This is a really good idea and I strongly agree. Using very specific exceptions
providing specialized getters allow users to refactor error handling easily.

Well, it seems only Phil and I think this localization stuff is important and
should be provided to users. If anyone steps up to support this idea, we could
end up gathering all use cases from this thread in [math] by having getMessage()
providing US-english messages that can be searched for (Stephen, Hen, Jörg),
having getSomeBasicPart() methods in specialized exception for complete(Jörg),
and having getLocalizedMessage() providing a new message (Phil and I). My goal
is only to add more user-friendliness, and of course only to [math]. However, if
nobody adds anything to the thread, I will remove my refactoring proposal.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message