I'm having some dilemmas on how to process and handle checked exceptions that are thrown by my domain objects while using Tapestry to create the web GUI as a presentation layer.
Assume I have a domain object, Foo
that throws FooException
on one of its methods:
public class Foo {
...
public void fooMethod throws FooException() {
...
}
...
}
Now, assume I have a Tapestry page called Bar
where Foo
object is, for example, being edited with BeanEditor
.
Now, to ensure illegal values are not passed to BeanEditor
for creating Foo
object, I can think of two basic ways to do that:
Tapestry field validation using
@Validate
annotationIn this case, if we can filter and check inputs via regexes or by limiting values or doing similar actions made available by
@Validate
we'll get a nifty error message next to the field we're editing and the submit will fail, thus making the user think about what he wrote there and how to fix it.Catching domain exception and doing actions based on it
I assume this scenario offers more options regarding what can and cannot be done. For example, if the used needs to enter
URL
and makes a mistake while doing so, theURL
constructor will throw its ownMalformedURLException
. We can catch that exception in our Java code, but my question is, what to do next and how?
Does Tapestry offer any special mechanisms of handing domain exceptions (checked and/or unchecked), other than that exception window that pops up when things break apart?
Are there any patterns on how to solve this particular problem?
Where do you draw the limit between common and ordinary exceptions like IndexOutOfBoundsException
and some domain-specific ones like FooException
?
:D