Java: Introduce ResultAnd<> and use it.

Java: Introduce ResultAnd<> and use it.

Never overload an int to be either a MojoResult or something else.

R=etiennej@chromium.org

Committed: https://chromium.googlesource.com/external/mojo/+/2c40ae03889a9c3e37c717c12db746993639e8d1

[etiennej, 2015-04-03 14:18:20]

LGTM

https://codereview.chromium.org/1057213003/diff/1/mojo/public/java/system/src...
File mojo/public/java/system/src/org/chromium/mojo/system/ResultAnd.java
(right):

https://codereview.chromium.org/1057213003/diff/1/mojo/public/java/system/src...
mojo/public/java/system/src/org/chromium/mojo/system/ResultAnd.java:12: public
class ResultAnd<A> {
(very optional) Something I've seen sometimes in these sort of classes is a
"ok()" method that directly checks if mMojoResult == MojoResult.OK, as this is
what people tend to want.

[qsr, 2015-04-03 14:32:54]

https://codereview.chromium.org/1057213003/diff/1/mojo/public/java/system/src...
File mojo/public/java/system/src/org/chromium/mojo/system/ResultAnd.java
(right):

https://codereview.chromium.org/1057213003/diff/1/mojo/public/java/system/src...
mojo/public/java/system/src/org/chromium/mojo/system/ResultAnd.java:12: public
class ResultAnd<A> {
On 2015/04/03 14:18:20, etiennej wrote:
> (very optional) Something I've seen sometimes in these sort of classes is a
> "ok()" method that directly checks if mMojoResult == MojoResult.OK, as this is
> what people tend to want.

 This class is sometimes used even when the result is not OK, so I prefer not to
add this method for the moment. If this is used a lot more, and comes again and
again, we can think about this.

[qsr, 2015-04-03 14:33:39]

Committed patchset #1 (id:1) manually as
2c40ae03889a9c3e37c717c12db746993639e8d1 (presubmit successful).