You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Alexander Klimetschek <ak...@adobe.com> on 2012/07/19 21:47:16 UTC
Re: hasProperty vs getProperty
On 12.06.2012, at 15:01, Julian Reschke wrote:
> Is this just to avoid catching exceptions? (keep in mind that the
> exception might be thrown anyway...)
No, if hasProperty() returns true, you don't expect the PathNotFoundEx and don't have to handle it for the purpose of semantics! There is no catch(PathNotFoundEx) in the code you quote :-)
You only have to handle the RepositoryException, which can then be seen as unrecoverable error condition (and is usually passed through and handled at a more generic layer in application code).
Cheers,
Alex
Re: hasProperty vs getProperty
Posted by Michael Dürig <md...@apache.org>.
On 15.8.12 5:31, Julian Reschke wrote:
> On 2012-08-14 15:47, Michael Dürig wrote:
>> ...
>> An even better way to handle this is to return an Option<T>. Guava has
>> something along these lines [1]. Unfortunately Guava's version of Option
>> is not a monad which makes it not as useful as it could be.
>> ...
>
> It looks cool first, but I'm totally unconvinced that replacing null
> checks by "isPresent()" checks really makes things better.
That's the particular problem with the Guava implementation which
doesn't provide map/flatMap methods. Having these you don't need
isPresent() but rather lift your operation into the monad.
Michael
>
> Best regards, Julian
Re: hasProperty vs getProperty
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-08-14 15:47, Michael Dürig wrote:
> ...
> An even better way to handle this is to return an Option<T>. Guava has
> something along these lines [1]. Unfortunately Guava's version of Option
> is not a monad which makes it not as useful as it could be.
> ...
It looks cool first, but I'm totally unconvinced that replacing null
checks by "isPresent()" checks really makes things better.
Best regards, Julian
Re: hasProperty vs getProperty
Posted by Michael Dürig <md...@apache.org>.
On 30.7.12 15:02, Alexander Klimetschek wrote:
> On 20.07.2012, at 14:58, Julian Reschke <ju...@gmx.de> wrote:
>
>> On 2012-07-20 14:41, Alexander Klimetschek wrote:
>>> On 20.07.2012, at 09:01, Julian Reschke wrote:
>>>
>>>> I agree with that, but that's how JCR works.
>>>
>>> Well, you have both options: if you use the has*() or (item|property|node)Exists() methods, and since PNFEx inherits from RepositoryEx, you can skip the try/catch for the application logic.
>>
>> That "works", but causes lots of unneeded work in the implementation;
>> which is exactly why I started this discussion.
>
> Yes, but this is one of the things that the infrastructure (i.e. JCR) should provide (without a penalty) instead of having to handle this again and again in your application or use ugly exception handling.
>
> But I agree that a get<Something>() returning null if it's not existing is also a very good idea, currently lacking from JCR.
An even better way to handle this is to return an Option<T>. Guava has
something along these lines [1]. Unfortunately Guava's version of Option
is not a monad which makes it not as useful as it could be.
Functional Java has a more complete implementation [2].
Michael
[1]
http://code.google.com/p/guava-libraries/wiki/UsingAndAvoidingNullExplained
[2]
http://functionaljava.googlecode.com/svn/artifacts/3.0/javadoc/fj/data/Option.html
>
> Cheers,
> Alex
>
Re: hasProperty vs getProperty
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 20.07.2012, at 14:58, Julian Reschke <ju...@gmx.de> wrote:
> On 2012-07-20 14:41, Alexander Klimetschek wrote:
>> On 20.07.2012, at 09:01, Julian Reschke wrote:
>>
>>> I agree with that, but that's how JCR works.
>>
>> Well, you have both options: if you use the has*() or (item|property|node)Exists() methods, and since PNFEx inherits from RepositoryEx, you can skip the try/catch for the application logic.
>
> That "works", but causes lots of unneeded work in the implementation;
> which is exactly why I started this discussion.
Yes, but this is one of the things that the infrastructure (i.e. JCR) should provide (without a penalty) instead of having to handle this again and again in your application or use ugly exception handling.
But I agree that a get<Something>() returning null if it's not existing is also a very good idea, currently lacking from JCR.
Cheers,
Alex
Re: hasProperty vs getProperty
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-07-20 14:41, Alexander Klimetschek wrote:
> On 20.07.2012, at 09:01, Julian Reschke wrote:
>
>> I agree with that, but that's how JCR works.
>
> Well, you have both options: if you use the has*() or (item|property|node)Exists() methods, and since PNFEx inherits from RepositoryEx, you can skip the try/catch for the application logic.
That "works", but causes lots of unneeded work in the implementation;
which is exactly why I started this discussion.
Best regards, Julian
Re: hasProperty vs getProperty
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 20.07.2012, at 09:01, Julian Reschke wrote:
> I agree with that, but that's how JCR works.
Well, you have both options: if you use the has*() or (item|property|node)Exists() methods, and since PNFEx inherits from RepositoryEx, you can skip the try/catch for the application logic.
Cheers,
Alex
Re: hasProperty vs getProperty
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-07-20 00:44, Alexander Klimetschek wrote:
> On 19.07.2012, at 22:22, Julian Reschke wrote:
>
>> On 2012-07-19 21:47, Alexander Klimetschek wrote:
>>> On 12.06.2012, at 15:01, Julian Reschke wrote:
>>>
>>>> Is this just to avoid catching exceptions? (keep in mind that the
>>>> exception might be thrown anyway...)
>>>
>>> No, if hasProperty() returns true, you don't expect the PathNotFoundEx and don't have to handle it for the purpose of semantics! There is no catch(PathNotFoundEx) in the code you quote :-)
>>
>> Except for race conditions.
>
> Yes, but that's a separate issue (atomic behavior). Any write operation based on that will be a separate call anyway.
>
> IMHO such application-level semantics (does exist vs. does not exist) should not be handled by exceptions. Simply because it is not what exceptions are designed for (exceptions), when the normal application logic expects this case. try/catch for normal logic is confusing.
I agree with that, but that's how JCR works.
It probably would be good to consider getProperties(...), returning an
Iterator, instead. Of course we first would need to optimize this in
Jackrabbit.
Best regards, Julian
Re: hasProperty vs getProperty
Posted by Alexander Klimetschek <ak...@adobe.com>.
On 19.07.2012, at 22:22, Julian Reschke wrote:
> On 2012-07-19 21:47, Alexander Klimetschek wrote:
>> On 12.06.2012, at 15:01, Julian Reschke wrote:
>>
>>> Is this just to avoid catching exceptions? (keep in mind that the
>>> exception might be thrown anyway...)
>>
>> No, if hasProperty() returns true, you don't expect the PathNotFoundEx and don't have to handle it for the purpose of semantics! There is no catch(PathNotFoundEx) in the code you quote :-)
>
> Except for race conditions.
Yes, but that's a separate issue (atomic behavior). Any write operation based on that will be a separate call anyway.
IMHO such application-level semantics (does exist vs. does not exist) should not be handled by exceptions. Simply because it is not what exceptions are designed for (exceptions), when the normal application logic expects this case. try/catch for normal logic is confusing.
Cheers,
Alex
Re: hasProperty vs getProperty
Posted by Julian Reschke <ju...@gmx.de>.
On 2012-07-19 21:47, Alexander Klimetschek wrote:
> On 12.06.2012, at 15:01, Julian Reschke wrote:
>
>> Is this just to avoid catching exceptions? (keep in mind that the
>> exception might be thrown anyway...)
>
> No, if hasProperty() returns true, you don't expect the PathNotFoundEx and don't have to handle it for the purpose of semantics! There is no catch(PathNotFoundEx) in the code you quote :-)
Except for race conditions.
> ...
Best regards, Julian