You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Cassie <do...@google.com> on 2008/03/31 12:22:53 UTC
Re: svn commit: r642404 - in /incubator/shindig/trunk/java/gadgets/src:
main/java/org/apache/shindig/gadgets/ main/java/org/apache/shindig/gadgets/http/
main/java/org/apache/shindig/social/ main/java/org/apache/shindig/social/opensocial/
main/java/or
One comment on the original cl:
Why do all of the social classes need throws GadgetException in their
signatures? I can't see anywhere this is thrown in the current social code,
and furthermore, the design is set up so that the service implementations
always handle their own exceptions and return a proper error code. Allowing
them to both return an error code and return an exception is just confusing.
Are you going to change this in the second submit?
Thanks!
- Cassie
On Sat, Mar 29, 2008 at 2:38 AM, Kevin Brown <et...@apache.org> wrote:
> Ok, this actually didn't work out as I planned. I'm going to roll this
> patch
> back and then include it with the Guice patch to make life less painful.
>
> Sorry everyone.
>
Re: svn commit: r642404 - in /incubator/shindig/trunk/java/gadgets/src:
main/java/org/apache/shindig/gadgets/ main/java/org/apache/shindig/gadgets/http/
main/java/org/apache/shindig/social/ main/java/org/apache/shindig/social/opensocial/
main/java/or
Posted by Cassie <do...@google.com>.
Cool. That can just be mapped to the ResponseError.INTERNAL_ERROR code.
Thanks!
- Cassie
On Mon, Mar 31, 2008 at 6:52 PM, Brian Eaton <be...@google.com> wrote:
> On Mon, Mar 31, 2008 at 3:22 AM, Cassie <do...@google.com> wrote:
> > Why do all of the social classes need throws GadgetException in their
> > signatures? I can't see anywhere this is thrown in the current social
> code,
> > and furthermore, the design is set up so that the service
> implementations
> > always handle their own exceptions and return a proper error code.
> Allowing
> > them to both return an error code and return an exception is just
> confusing.
>
> Ah, I'd missed the error handling in the original design. There just
> needs to be some mechanism to return an error from those APIs, it
> doesn't have to be GadgetException. If a RemoteContentFetcher were to
> throw a GadgetException, how should that exception be mapped to a
> ResponseError?
>
Re: svn commit: r642404 - in /incubator/shindig/trunk/java/gadgets/src: main/java/org/apache/shindig/gadgets/ main/java/org/apache/shindig/gadgets/http/ main/java/org/apache/shindig/social/ main/java/org/apache/shindig/social/opensocial/ main/java/or
Posted by Brian Eaton <be...@google.com>.
On Mon, Mar 31, 2008 at 3:22 AM, Cassie <do...@google.com> wrote:
> Why do all of the social classes need throws GadgetException in their
> signatures? I can't see anywhere this is thrown in the current social code,
> and furthermore, the design is set up so that the service implementations
> always handle their own exceptions and return a proper error code. Allowing
> them to both return an error code and return an exception is just confusing.
Ah, I'd missed the error handling in the original design. There just
needs to be some mechanism to return an error from those APIs, it
doesn't have to be GadgetException. If a RemoteContentFetcher were to
throw a GadgetException, how should that exception be mapped to a
ResponseError?