I am still missing a use case that validates such changes... adaptTo is already
a slightly hacky/magic approach, we should not introduce more magic :)
Cheers,
Alex
On 28.07.2014, at 21:49, Marius Petria mpet...@adobe.com wrote:
Hi,
I just read this thread and it might be that I do not
I just came up with another example from CQ:
In Sightly you can instantiate a model via the use API [1].
Since that logic will first try to adapt from Resource then from Request and as
fallback tries to instantiate the class leveraging the default constructor, you
won’t get any exceptions in
Hi Konrad,
In this case, I don't see how any of the options in this thread would
actually help because the code which calls adaptTo() is not under your
control. So there would be no way for the caller (i.e. your Sightly
script) to indicate that such an exception should be thrown.
Regards,
Justin
In my regard in this case a RuntimeException would be fine. That would be
propagated correctly to the script level.
So whenever a model class has the model annotation and something went wrong
during the injection throwing a runtime exception would be correctly propagated
and no other option
You're missing my point. How would your Sightly script indicate that a
RuntimeException should be thrown in the first place? Or are you
suggesting that Sightly assume that this is always the case?
On Mon, Jul 28, 2014 at 12:07 PM, Konrad Windszus konra...@gmx.de wrote:
In my regard in this case
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
On 07.07.2014, at 18:42, Carsten Ziegeler cziege...@apache.org wrote:
This doesn't really convince me - the same argument would hold true for
every API where the exception (cause) is logged, but the method just gives
back true/false,object/null. Even for APIs throwing an exception it might
be
On 07.07.2014, at 18:14, Justin Edelson jus...@justinedelson.com wrote:
I found a more concrete example in the AEM codebase (so apologies to
the non-Adobe people on this thread who will just have to take my word
for it). The adapter factory which adapts Resources into Scene7 set
objects makes
Hi,
On Thu, Jul 3, 2014 at 3:07 PM, Alexander Klimetschek
aklim...@adobe.com wrote:
On 03.07.2014, at 13:58, Justin Edelson jus...@justinedelson.com wrote:
It won't work :) This is a hugely non-backwards compatible change. It
happens to be binary compatible, but it is not semantically
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:
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
Hi,
On Mon, Jul 7, 2014 at 5:57 PM, Alexander Klimetschek
aklim...@adobe.com wrote:
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
2014-07-07 18:14 GMT+02:00 Justin Edelson jus...@justinedelson.com:
Hi,
I found a more concrete example in the AEM codebase (so apologies to
the non-Adobe people on this thread who will just have to take my word
for it). The adapter factory which adapts Resources into Scene7 set
objects
Provide a meaningful error message to the author or at least to the developer
(leveraging the WCMDeveloperMode). By meaningful I don’t talk about something
hidden within the logs.
Konrad
On 07 Jul 2014, at 18:27, Carsten Ziegeler cziege...@apache.org wrote:
2014-07-07 18:14 GMT+02:00 Justin
2014-07-07 18:29 GMT+02:00 Konrad Windszus konra...@gmx.de:
Provide a meaningful error message to the author or at least to the
developer (leveraging the WCMDeveloperMode). By meaningful I don’t talk
about something hidden within the logs.
This doesn't really convince me - the same argument
On 03.07.2014, at 09:12, Konrad Windszus konra...@gmx.de wrote:
- The client can decide how to expose that error (whether just logging is
fine or something more obvious). This cannot be achieved by just setting up a
utility method, because that one does only see the null return value and not
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(ClassAdapterType
On 03 Jul 2014, at 10:50, Alexander Klimetschek aklim...@adobe.com wrote:
I guess it would make sense to have adapterfactories et. al. to work like
this:
a) if it is not of the desired type, i.e. cannot semantically be adapted,
return null
b) if it fails due to some actual exception,
Hi
Am 03.07.2014 um 11:10 schrieb Konrad Windszus konra...@gmx.de:
On 03 Jul 2014, at 10:50, Alexander Klimetschek aklim...@adobe.com wrote:
I guess it would make sense to have adapterfactories et. al. to work like
this:
a) if it is not of the desired type, i.e. cannot semantically be
Hi
Am 03.07.2014 um 12:29 schrieb Konrad Windszus konra...@gmx.de:
The AdapterFactory should clearly state, which RuntimeExceptions are thrown
under which condition. You know in most of the cases, which AdapterFactory is
responsible for your adaptTo-method (or you should be able to find out
Hi,
On Thu, Jul 3, 2014 at 4:50 AM, Alexander Klimetschek
aklim...@adobe.com wrote:
On 03.07.2014, at 09:12, Konrad Windszus konra...@gmx.de wrote:
- The client can decide how to expose that error (whether just logging is
fine or something more obvious). This cannot be achieved by just
* My original suggestion of using a Result interface. This requires
more verbose code on the caller side -- the caller needs to check a
success flag -- but allows for fine-grained information (which would
be appropriate for a validation use case).
+1
On 03.07.2014, at 12:19, Felix Meschberger fmesc...@adobe.com wrote:
I guess it would make sense to have adapterfactories et. al. to work like
this:
a) if it is not of the desired type, i.e. cannot semantically be adapted,
return null
example: resource.adaptTo(Node.class) for a resource
On 03.07.2014, at 13:58, Justin Edelson jus...@justinedelson.com wrote:
It won't work :) This is a hugely non-backwards compatible change. It
happens to be binary compatible, but it is not semantically compatible
(which is in some ways just as important). Callers of adaptTo() assume
(because
Just reading up on this and have the basic question: what is the motivation for
passing through the exceptions?
From what I can see it is simply that the exceptions become visible to the
developer, which can be done by properly logging them (in the adapterfactories
etc.). It was mentioned that
The example Stefan gave [1] is just about removing the boilerplate of the null
check + throwing a runtime exception, which could be handled using a static
utility method (adaptOrThrow, but outside the adaptable interface).
yes, you are right - this would be an alternative for this simple
Hi,
On Tue, Jul 1, 2014 at 9:07 AM, Felix Meschberger fmesc...@adobe.com wrote:
..there are options available...
Just a wild idea, how about this:
Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class));
which could be handled by the AdapterManagerImpl, by wrapping whatever
adapter it
On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
...how about this:
Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class));
Actually, rereading SLING-3714, this can be made simpler with generics
Foo f = someObject.adaptTo(RequireAdapterFoo.class));
Regarding 1) Having such a Result class would mean that all consumer would need
to unwrap the exception first. So instead of being forced of implementing a
null-check (as with the old solution) one would need to implement another
check. I want to prevent such a burden to the consumers.
Adding a new interface would require us to implement it all over the place
and as Felix points out, client code would always need to check whether the
new interface is implemented or not Having to methods, like hasAdapter and
adaptOrThrow does not work very well as between the two calls things
adaptTo() is currently commonly used as a test, similar to instanceof.
Throwing and catching to return null is a very poor implementation
(performance-wise) for this use.
Adding a hasAdapter() or canAdaptTo() might decrease the number of
implementations that think throwing is OK, but only if the
It is not (only) about throwing exceptions in case no suitable adapter is
available. It rather is about the fact, that today the adaptTo is a barrier for
all kinds of exceptions. In some cases the adaptation fails for a specific
reason (one example is Sling Models where injection fails, another
adaption and validation are different concerns
Carsten
2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com:
We could solve that by defining a specific exception for
adaptation-not-possible and then catch only that.
Of course that would leak tons of exceptions from code written before that
Hi Carsten,
Can you say more? (I'm not sure I understand what you're getting at)
Thanks,
Jeff.
On 01/07/2014 09:56, Carsten Ziegeler cziege...@apache.org wrote:
adaption and validation are different concerns
Carsten
2014-07-01 10:55 GMT+02:00 Jeff Young j...@adobe.com:
We could
Sure :) For the adapter pattern, the client does not care why the adaption
failed, the client is just interested in the result (success or not)
Validation is a different beast, if validation fails you want to know
specific reasons why it failed - and this can be multiple.
I tried to explain in my
I like that approach. It is backwards-compatible and allows the developers to
decide whether they want to check for null or to rely on exceptions.
The AdapterManagerImpl indeed would need to deal with such a parametrisation
and in addition the javadocs would need to be adjusted to make it clear
class.
i assume it could be implemented using a ThreadLocal or similar as well?
stefan
-Original Message-
From: Konrad Windszus [mailto:konra...@gmx.de]
Sent: Tuesday, July 01, 2014 11:58 AM
To: dev@sling.apache.org
Cc: Bertrand Delacretaz
Subject: Re: adaptTo and results
I like
Hi Carsten,
Sure, but Konrad has a point in that I think sometimes the client *does*
care why the adaption failed. For instance, if it had to do with
something entirely different from whether or not adaption would normally
work.
Let's say that I have a resource that should adapt to XYZ, but
Message-
From: Konrad Windszus [mailto:konra...@gmx.de]
Sent: Tuesday, July 01, 2014 11:58 AM
To: dev@sling.apache.org
Cc: Bertrand Delacretaz
Subject: Re: adaptTo and results
I like that approach. It is backwards-compatible and allows the developers to
decide whether they want
So if your adapter is buggy and you get an exception, what do you do with
it?
Carsten
2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com:
Hi Carsten,
Sure, but Konrad has a point in that I think sometimes the client *does*
care why the adaption failed. For instance, if it had to do with
and result in an error log message.
stefan
-Original Message-
From: Carsten Ziegeler [mailto:cziege...@apache.org]
Sent: Tuesday, July 01, 2014 12:14 PM
To: dev@sling.apache.org
Subject: Re: adaptTo and results
So if your adapter is buggy and you get an exception, what do you do
@sling.apache.org
Subject: Re: adaptTo and results
So if your adapter is buggy and you get an exception, what do you do with
it?
Carsten
2014-07-01 12:08 GMT+02:00 Jeff Young j...@adobe.com:
Hi Carsten,
Sure, but Konrad has a point in that I think sometimes the client *does
I just fix it in the code ;-). Those exceptions should only happen during
runtime (due to some false assumptions).
For the same reasons methods do throw IllegalArgumentExceptions in case a given
parameter is null
[mailto:cziege...@apache.org]
Sent: Tuesday, July 01, 2014 12:21 PM
To: dev@sling.apache.org
Subject: Re: adaptTo and results
Yes, but right now you would get an NPE accessing the object - so you
already have a runtime exception and don't need to check for null (I'm not
arguing that this is a good
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(RequireAdapterFoo.class));
* Foo f = someObject.adaptToUnchecked(Foo.class);
Cheers,
Stefan
On 7/1/14 11:57 AM, Konrad Windszus konra...@gmx.de
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(RequireAdapterFoo.class));
* Foo f =
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
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
Well, for one thing, display it in the Developer Mode console (or whatever
other debugging UIs my app happens to have).
Jeff.
On 01/07/2014 11:14, Carsten Ziegeler cziege...@apache.org wrote:
So if your adapter is buggy and you get an exception, what do you do with
it?
Carsten
2014-07-01
To: dev@sling.apache.org
Cc: Bertrand Delacretaz
Subject: Re: adaptTo and results
I like that approach. It is backwards-compatible and allows the developers
to
decide whether they want to check for null or to rely on exceptions.
The AdapterManagerImpl indeed would need to deal
Hi
Am 01.07.2014 um 09:44 schrieb Bertrand Delacretaz bdelacre...@apache.org:
On Tue, Jul 1, 2014 at 9:41 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
...how about this:
Foo f = someObject.adaptTo(RequireAdapter.for(Foo.class));
Actually, rereading SLING-3714, this can be made
51 matches
Mail list logo
