On 4-Dec-07, at 9:03 AM, Stian Soiland wrote:
On 12/3/07, Paul J. Lucas [EMAIL PROTECTED] wrote:
Funny, because java.io.FileNotFoundException is derived from
IOException. So clearly there's precedent.
Did you notice the io package name? :-) The exceptions here are
about resources, not
On Dec 4, 2007, at 3:03 AM, Stian Soiland wrote:
On 12/3/07, Paul J. Lucas [EMAIL PROTECTED] wrote:
Funny, because java.io.FileNotFoundException is derived from
IOException. So clearly there's precedent.
Did you notice the io package name? :-) The exceptions here are
about resources, not
On 12/3/07, Paul J. Lucas [EMAIL PROTECTED] wrote:
Funny, because java.io.FileNotFoundException is derived from
IOException. So clearly there's precedent.
Did you notice the io package name? :-) The exceptions here are
about resources, not IO.
Generally I think having support for throwing
On 29-Nov-07, at 3:06 PM, Paul J. Lucas wrote:
On Nov 28, 2007, at 11:31 PM, Sumit Lohia wrote:
I have done something similar in my project but the exception
hierarchy is
unchecked. This allows me to use the same set of exceptions in my
DAO code,
and Controller code and not have to add
On Nov 29, 2007 10:57 AM, Rob Heittman [EMAIL PROTECTED] wrote:
Hmmm. I feel myself spiraling back to the interfaces vs classes question.
Don't go into the light! :-) Isn't this just more evidence that it's very
hard to specify interfaces in unstable APIs?
But now you've got me thinking.
On Nov 29, 2007, at 6:30 AM, Tim Peierls wrote:
However, I don't have a concrete proposal, and I don't see an easy
way to do this without breaking code for 1.1m1 users.
Personally, I'd prefer to break an API rather than have to live with
a hacked API forever. Since Restlet is currently a
Isn't this just more evidence that it's very hard to specify interfaces in
unstable APIs?
Yep. And yet, why it's tempting to use them in certain ways. In full
disclosure mode, these public API design questions interest me deeply for
reasons of state not strictly related to Restlet, so
Tim,
I like where you're going with this. Having opt-in interface
inheritance rather than opt-out implementation extension seems a lot
more flexible and a lot lighter weight. Framework helpers, such as
content negotiation, could be injected as (mockable--hah! back to
testing)
Hello all,
I agree fully with Paul. Exceptions are the modern way to handle things,
that don't are the normal way. The same thing should be possible for
doPut(..), doGet(..), getRepresentation(.) and so on on subclasses of
org.restlet.resource.Resource.
greetings
Stephan
Paul J. Lucas
On Nov 28, 2007 5:38 AM, Stephan Koops [EMAIL PROTECTED] wrote:
I agree fully with Paul. Exceptions are the modern way to handle things,
that don't are the normal way. The same thing should be possible for
doPut(..), doGet(..), getRepresentation(.) and so on on subclasses of
Yes, you are right.
greetings
Stephan
Tim Peierls schrieb:
On Nov 28, 2007 5:38 AM, Stephan Koops [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
I agree fully with Paul. Exceptions are the modern way to handle
things,
that don't are the normal way. The same thing should be
Hi Paul,
Why doesn't the Restlet framework make more use of exceptions? Why
should I have to do something like this:
if ( /* disaster */ ) {
response.setStatus( CLIENT_ERROR_WHATEVER, message );
return;
}
when I could do something like this:
12 matches
Mail list logo
