So, I may be missing the obvious, but if the method's precondition is that it
receives an int[], shouldn't you be doing input validation anyway?
if (userData instanceof int[] ((int[]) userData.length 0) {
return userData;
}
else {
getResponse().setStatus(Status.BAD_REQUEST);
}
Or are
Hi David and Adam,
Thanks for the follow up and general comment on the list. I agree and also
suggest people to follow StackOverflow for general QA. We try to be
present over there as well, but this list will stay the place of more
personal conversations.
After the release of the 'Restlet in
For others coming upon this thread, I disabled the long scan by (essentially)
disabling the WAR protocol:
public class OverridenSpringServerServlet extends SpringServerServlet {
@Override
protected Client createWarClient(Context context, ServletConfig config)
{
Jerome,
Thanks for your thoughts. My comments were not a knock against the Restlet
team. We know you all are working at full steam! I will continue to think how
I may be able to help with community documentation.
Thanks,
-Adam
--
Hi Jerome,
Thank you for that information. Congratulations for the book, by the way. I
found it very useful. APISpark looks very interesting, too. I look forward to
getting my hands dirty with Restlet.
Regards,
=David
On 30 Apr 2013, at 10:48 PM, Adam Mc wrote:
Jerome,
Thanks for your
Hi Jon,
In method 1, there is a need for input validation, as you say... but when
there is input provided and there are parse errors, the handler simply gets
a *null* argument and is not able to catch the exception.
In method 2, the exception describes the parse error---which I want to feed
back
6 matches
Mail list logo
