On 4/11/07, Paul Sandoz <Paul.Sandoz_at_sun.com> wrote:
>
>
> "2XX and 3XX codes aren't really exceptional but rather business as
> usual so they *should not* be treated as exceptions, which are
> associated with errors".
Agreed on this score. Also would suggest that 4xx and 5xx error codes are
thrown as unchecked (semantically unrecoverable) exceptions.
Ahh, as I see you're doing..
> I suggest that we explore an intermediary path where 4xx and 5xx codes can
> > be expressed as exceptions.
>
> I agree. We took this approach too. We also found it useful to have
> exceptions for common errors, like NotFoundException that extends from a
> general WebApplicationException for 404 errors (although this exception
> is not in the java doc).
I have a bit of a problem with WebApplicationException--why do we have a
root unchecked exception? It is not abstract so I imagine it is intended to
be thrown--what case might it be thrown in (as WAE)?
I've no problem with root exceptions for apis so long as they are checked (
i.e. IOException -- catching it says, "we expect to recover from any kind of
IO problem"). I dont get the thinking behind root unchecked exceptions
(especially as I dont see a case when WAE is thrown directly--is it intended
to wrap-and-rethrow other exceptions?).
I know some other standards and frameworks (jmx comes to mind) employ
this--but I've never heard a good explanation for it.
I also dont like that the response object and/or a status code is embedded
in it--this makes it look like a framework utility to me ("extend me for
exception functionality!"), in which case it's fine but then should NOT be
declared public.