That would be solved by just stating that RuntimeExceptions are allowed as alternative to returning null for all AdapterFactories (i.e. no API change necessary) and making sure that those exceptions are either being caught within the AdapterManagerImpl or just propagated to the caller.
On 01 Jul 2014, at 13:08, Carsten Ziegeler <cziege...@apache.org> wrote: > Ok, this would solve the throw if adaption is not possible case, what about > the validation use case? > > Carsten > > > 2014-07-01 12:50 GMT+02:00 Bertrand Delacretaz <bdelacre...@apache.org>: > >> On Tue, Jul 1, 2014 at 12:38 PM, Stefan Egli <stefane...@apache.org> >> wrote: >>> I like the idea too, but I guess it's merely a question of taste as to >>> which of the following two options is nicer: >>> * Foo f = someObject.adaptTo(RequireAdapter<Foo>.class)); >>> * Foo f = someObject.adaptToUnchecked(Foo.class); >> >> The big difference is that the first variant requires no API changes >> and only requires code changes in AdapterManagerImpl (I think - >> haven't looked in full detail ;-) >> >> -Bertrand >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
