I think it is a good idea for sure, but the trick is always how to do
throw exceptions at the "service level" that can 1) be usable by the ui
for useful error reporting and 2) not depend on any specific ui classes.
Providing a hook at the UI level for exceptions seems like the easy
part. The hard part is given an exception, what does it mean? Providing
keys to exceptions rather then messages seems doable, but we have to be
weary of other code that needs to report the exception. Like the
dispatcher. So the stuff that takes the key and parameters and looks up
the appropriate i18n message would have to be available at the "service"
level".
There would also be the large task of going through the code base and
i18nizing our exception messages... no easy task.
Is there a "standard" way to i18nize exceptions in java? I know that
Martin does this with the referencing modules in geotools, or maybe that
was just logging... can't quite remember.
Anyways, I think doing this completely will be quite an undertaking.
Although first coming up with a scheme that will work, and gradually
porting code to use i18nized exceptions seems like an doable migration path.
My 2c.
-Justin
Andrea Aime wrote:
> Hi,
> wondering if anyone looked in consistent and decent looking
> error reporting for the Wicket UI, in particular for those
> errors that are not recoverable.
> Consider this fragment of code:
>
> CoverageStoreInfo cstore = (CoverageStoreInfo) store;
> CatalogBuilder builder = new CatalogBuilder(getCatalog());
> builder.setStore(store);
> AbstractGridCoverage2DReader reader = (AbstractGridCoverage2DReader)
> (cstore.getFormat()).getReader(cstore.getURL());
> try {
> CoverageInfo ci = builder.buildCoverage(reader);
> } catch(Exception e) {
> // hmmm.. what now???
> }
>
> The exception the builder throws is not recoverable,
> we can only admit defeat and give up... but we should
> do that in style, giving the user something to read and the
> devs something to look at for debugging purposes.
>
> I guess I'd like to have an exception be thrown, and
> have some hook somewhere in wicket that take it,
> lookup a i18n error message using a key and an
> Object[] for params, reports the message, and
> provide provide a copy/paste friendly section
> for the full stack trace.
>
> First off, what other devs think of this idea?
> And does anyone know if it's actually doable?
> If no one already knows, I'll look it up.
>
> The important point is more to have a consistent
> way to deal with these cases, so I'm looking forward
> to hear about options on this one.
>
> Cheers
> Andrea
>
--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
