On 07.07.2014, at 17:08, Carsten Ziegeler <cziege...@apache.org> wrote:
> 2014-07-07 14:55 GMT+02:00 Justin Edelson <jus...@justinedelson.com>: > >> Here's a sightly more real world case... let's say you have a call like >> this: >> >> Comment comment = resource.adaptTo(Comment.class); >> >> And for a Resource to be successfully adapted to a Comment, it must >> satisfy two criteria: >> 1) The resource type must be myco/comment >> 2) It must have a property called "commentType" (OK, this part isn't >> so real world). >> >> Right now, the caller has no way of knowing which of these critera >> wasn't met. That's IMHO the crux of this request - to provide a way >> for AdapterFactories to surface the failure reason back to the caller. >> >> > Hmm, this assumes the caller can do something meaningful with it. Given > your example, what could the client do? Right. In this case I would assume that if 1) is present, you get a Comment back, otherwise null. Then Comment has a getter method for the type 2), which would also handle the case of a missing type: usually you would fall back to a default if no type is specified, since that reduces the constraints the content has to follow; but you could also have the application handle the no-type case itself and fail in some way (as you were trying to with an exception that is passed through from adapterfactory to application code). Next example please :D Cheers, Alex
