Selon Jörg Schaible <[EMAIL PROTECTED]>:
> 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. Luc --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
