Jerome Louvel wrote:
>> Paul and I thought about that but in the end we decided against it
>> for the reason that a redirection and many other 2XX and 3XX codes
>> aren't really exceptional but rather business as usual so
>> they should
>> be treated as exceptions which are associated with errors. Also
>> catching exceptions is relatively expensive.
>
I think Marc meant to say:
"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".
> From a POJO point of view, it does makes sense to rely on exceptions for all
> client and server error statuses.
>
> However, for all success and redirection statuses, the mapping to the
> exception concept is not as clean.
>
> 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).
> Redirections could be expressed using another
> mechanism such as:
>
> public class Context {
> // Success methods
> void successOk();
> void successCreated();
>
> // Redirection methods
> void redirectPermanent(uri);
> void redirectSeeOther(uri);
> void redirectTemporary(uri);
>
> // Direct status manipulation
> int getStatus();
> String getReasonPhrase();
> void setStatus(int code);
> void setReasonPhrase(String reasonPhrase);
> }
>
Looks a bit like a subset of HttpServletResponse :-)
I want to point out, without getting into the pros/cons of each approach
just yet!, that this functionality is also expressed by HttpResponse and
specializations of, see the Created and TemporaryRedirect classes. The
WebApplicationException constructor can also take a HttpResponse, thus
it is possible to return a representation as the body of the error.
Paul.
--
| ? + ? = To question
----------------\
Paul Sandoz
x38109
+33-4-76188109