Java folks,
Currently we are using the concrete subclasses to ResponseItem to represent
either a success response with data or an error response with a status code
and message. I would like to propose that we have errors be raised by
throwing runtime exceptions in the service implementations rather than
returning objects with error statuses.
I believe this makes sense for a couple of reasons.
1. Code which implements preconditions to service method execution can be
reused among service methods returning different types. Consider a
hypothetical restriction on writing app data that the viewer must be the
owner. If we allow for exceptions then we can re-use a call like this...
SocialApiPrecondition.viewerIsOwner(user, securityToken, "Viewer must be
owner to set app data")
.. everywhere that restriction exists as opposed to
if (user.equals(securiyToken.getOwner()) {
return new ResponseItem(ResponseError.BAD_REQUEST, "Viewer must be
owner to set app data"); // or new DataCollection | RestfulCollection |
RestfulItem depending on the return type of the method
}
2. Methods which succeed and return nothing can now safely return <void>
which seems cleaner
3. It allows validation of inputs in code which is not aware of the ultimate
return type.
There has been some dicussion of allowing for partial-success of calls where
we would still return some data and a response code indicating something
other than complete success. I dont think this approach precludes that in
the future, it just simplifies the coding model for the 80+% case where an
error is a complete failure.
I'd like to convert the code over to this model, remove the error-status
constructors from the response objects and introduce a new RuntimeException
to capture the error details which would just be caught in the handler or
servlet layer.
Thoughts
-Louis
