Either at the handler layer or the servlet layer (I think the latter
is easier), but yes.
On Wed, Aug 27, 2008 at 8:41 AM, Ian Boston <[EMAIL PROTECTED]> wrote:
> Is the intention to catch the SocialApiException somewhere near the protocol
> handler and convert to a suitable error response ?
>
> If so, IMHO +1
>
> Ian
>
> On 27 Aug 2008, at 16:30, Adam Winer wrote:
>
>> Since we're trying to clean up the codebase to freeze it: I'd like to
>> clean up a few items in the Service APIs.
>>
>> (1) Get error code and message out of
>> RestfulItem/RestfulCollection/DataCollection and into an exception,
>> so:
>>
>> PersonService {
>> Future<RestfulCollection<Person>> getPeople(...);
>> Future<RestfulItem<Person>> getPerson(...);
>> }
>>
>> becomes:
>>
>> PersonService {
>> // Note: the Future may also throw a SocialApiException (wrapped in
>> an EvaluationException)
>> Future<RestfulCollection<Person>> getPeople(...) throws
>> SocialApiException
>> Future<Person> getPerson(...) throws SocialApiException
>> }
>>
>> RestfulItem goes away entirely, and RestfulCollection doesn't extend
>> ResponseItem. ResponseItem can entirely disappear from the SPI, and
>> can move out of org.apache.shindig.social and into
>> o.a.s.s.opensocial.service alongside of RequestItem.
>>
>> One advantage of this change is that it makes it easy to write generic
>> preconditions across datatypes, and gets rid of early returns from
>> service implementations, which are a bit of a code smell.
>>
>> (2) ResponseError should go somewhere other than the top package - I
>> think it belongs in opensocial.model.
>>
>> (3) Mutators should be able to return Void instead of an untyped Object,
>> so:
>>
>> Future<ResponseItem> createActivity(...);
>>
>> becomes;
>>
>> Future<Void> createActivity(...) throws SocialApiException;
>>
>> -- Adam Winer
>
>
