[Geoserver-devel] Error reporting in the wicket UI

GeoServer GeoServer Developer
1

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

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

2

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.

3

On Mon, Mar 16, 2009 at 12:22 PM, Andrea Aime <aaime@anonymised.com> 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.

Hi,
I saw this and thought I would chime in. Even though I am a complete
noob at geoserver I have a bunch of wicket experience and love the
framework. If you already know this I apologize. Wicket has a
completely pluggable api for exception handling, although the hooks
are in various places. You can set pages for various kinds of errors
on the Apllication itself, or override onRuntimeException in
WebRequestCycle. Additionally, if you have the configuration param for
wicket filter set to DEVELOPMENT in the web.xml, the developer will
get pages with a nicely formatted stack trace. This page provides
comprehensive information:
http://cwiki.apache.org/confluence/display/WICKET/Error+Pages+and+Feedback+Messages.

hth,
jim

4

Justin Deoliveira ha scritto:

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".

Oh yeah, I did not really think this that deep. I was more concerned
about situations that occur at the UI level only.
Consider a case in which an admin is using multiple tabs in the
browser, keeps a list of layers in one, removes one layer in the
other, clicks on the same layer in the first... boom!
And "boom" it should be, but somehow controlled.
So far I threw IllegalArgumentExceptions or some other sort of exception, was trying to figure out a better way to handle this.
Maybe we should just have the code redirect to a well known error
page that informs the user of what happened using an error key,
and that page then has a link to go back to the home page,
and space for a stack trace as well if we want.
The same page could be use as a generic error handler, if it
does not receive any error key for i18n it can generally report
and unexpected error?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

5

Oh yeah, I did not really think this that deep. I was more concerned
about situations that occur at the UI level only.
Consider a case in which an admin is using multiple tabs in the
browser, keeps a list of layers in one, removes one layer in the
other, clicks on the same layer in the first... boom!
And "boom" it should be, but somehow controlled.
So far I threw IllegalArgumentExceptions or some other sort of exception, was trying to figure out a better way to handle this.
Maybe we should just have the code redirect to a well known error
page that informs the user of what happened using an error key,
and that page then has a link to go back to the home page,
and space for a stack trace as well if we want.
The same page could be use as a generic error handler, if it
does not receive any error key for i18n it can generally report
and unexpected error?

The page that James sent out has some useful info in it (which I am sure is not news to you). But it seems easy to set one big bad custom page for all runtime exceptions. And easy to override on a page by page basis.

Question about error keys. How are they generated? Is the error page created with a specific error key? Or is the message of an exception treated like an error key and a resource lookup performed to find the message for it? Or something else?

Cheers
Andrea

--
Justin Deoliveira
OpenGeo - http://opengeo.org
Enterprise support for open source geospatial.