Hi, I just read this thread and it might be that I do not understand all the reasons behind surfacing exceptions through adaptTo. However, I wanted to share with you a variation of Bertrand¹s initial proposal which allows the consumer of the API to explicitly require an adaptation that throws exceptions.
Instead of * Foo f = someObject.adaptTo(RequireAdapter<Foo>.class)); One can use a double adaption * StrictAdaptable strictAdaptable = someObject.adaptTo(StrictAdaptable.class)); * Foo f = strictAdaptable.adaptTo(Foo.class)); where StrictAdaptable is just like Adaptable but in addition it specifies that adaptTo never returns null and can throw RuntimeExceptions. The boiler plate of ³double adaption² can be extracted in an adaptOrThrow util. In case of validation a more specific interface (ValidationAdaptable) can be used, for which the contract of adaptTo specifies that it throws ValidationException. WDYT? Marius On 7/3/14, 12:06 PM, "Bertrand Delacretaz" <bdelacre...@apache.org> wrote: >Hi, > >On Tue, Jul 1, 2014 at 5:16 PM, Felix Meschberger <fmesc...@adobe.com> >wrote: >> Am 01.07.2014 um 09:44 schrieb Bertrand Delacretaz >><bdelacre...@apache.org>: >> ...Unfortunately, I don't think this works, because the adaptTo >>signature is: >> >> public <AdapterType> AdapterType adaptTo(Class<AdapterType> type); >> >> Hence the return type is the same as provided as the argument, that is >>if you pass >> RequireAdapter<Foo>, you get a RequireAdapter<Foo> object and not a Foo >>object... > >You're right, I overlooked that. > >The someObject.adaptTo(RequireAdapter.for(Foo.class)) variant should >work if for(...) returns Foo.class but uses a ThreadLocal to tell the >AdapterManagerImpl about the options. Not sure if it's worth the >effort or if a new API is better, we could implement a bridge between >the new and old API to avoid having to change all existing adapters. > >I see that the use case is under discussion anyway, so let's see what >comes out of that... > >-Bertrand
