Gabriel Roldán ha scritto:
...
> 
> I'm sure others do it by defining well known error codes for well known 
> exception messages.
> For instance, the ArcSDE Java API has SeException which in turn has 
> SeException.getSeError():SeError
> and SeError defines the error constants 
> <http://edndoc.esri.com/arcsde/9.1/java_api/docs/com/esri/sde/sdk/client/seerror.html>

Cool, this works fine, but we have to accept a limitation with 
parametrized messages (the ones that want to report, for example,
the name of the datastore that failed, or the WKT of the srs code that 
was not recognized), which is, we either do not parametrize the error
messages at all, or we do so using only the objects that the caller
can see (such as, for example, "layer X could not be auto  configured" 
because the feature type name is a known item in the context of the
caller.

> we could do something similar, ie, either having our own exception which 
> overrides getLocalizedMessage() or that defines getMessage(Locale):String, 
> depending on what we want to achieve. Then we could decide if we want the 
> message in the stack trace to be always in english or we could anyway figure 
> out what the problem is by the error code in the stack trace message.

The issue I'm seeing here is that localized exceptions would use a 
parallel i18n system, not the one used by wicket. Since we don't really
need to parametrize the error messages for REST return values (I'm still
solidly convinced a programming API using only english is good enough,
other may have a different opinion), and that the i18n subsystem is 
Wicket specific (we don't want it to taint the other modules, right?)
I'd say the above approach (error codes) is good enough, and that if
we need more, we can roll subclasses that do provide the parameters
as fields of the exception.

Seems like a good approach to me, if nobody objects, I'll follow it.
Maybe using enums instead of integer contants ;)

Cheers
Andrea

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Reply via email to