utility function for creating observables for closeable resources

[abersnaze]

#1199 the answer to the issue was nagging at me when I tried to recommend it recently. I think @zsxwing's solution was ok but would fail if there were repeated subscriptions to the observable returned. I created a utility function on StringObservable to make it easier to use using() for objects that implement the AutoCloseable interface.

PS. I made a breaking change to arguments of join(Observable<Object>) to join(Observable<String>) and added a Observable<String> toString(Observable<Object>) to make up for it.

PPS. I made a UnsafeFunc0<R> scoped to this class but I would like to have UnsafeFunc<N> in the rx.functions packages and have Func<N> extends UnsafeFunc<N>. Makes it clear to the compiler that we don't expect the code the user's are giving us to always work. This also helps the users because they don't have to always fill their closures with try catch blocks

() -> new FileReader(file)

vs.

() -> {
    try {
        return new FileReader(file);
    } catch (Exception e) {
        throw new RuntimeException(e);
    }
}

[cloudbees-pull-request-builder]

RxJava-pull-requests #1182 SUCCESS
This pull request looks good

[akarnokd]

This won't work with Java 6.

[abersnaze]

I guess I'll switch it to Closeable then

[cloudbees-pull-request-builder]

RxJava-pull-requests #1186 SUCCESS
This pull request looks good

[benjchristensen]

Can someone else involved in StringObservable review this please?

Also, this needs to be rebased now as it collides with another change that was merged.

[cloudbees-pull-request-builder]

RxJava-pull-requests #1191 FAILURE
Looks like there's a problem with this pull request

[abersnaze]

whoops bad merge

[cloudbees-pull-request-builder]

RxJava-pull-requests #1192 SUCCESS
This pull request looks good

[abersnaze]

@davidmoten can you take a look?

[davidmoten]

yep will do

[davidmoten]

I might have missed something here. I don't see that the UnsafeFunc0 adds much. After all every Func0 is potentially unsafe inasmuch as it can throw a RuntimeException for instance.

[davidmoten]

I see your point about the advantage when writing lambdas. Could you equivalently have a utility function that wrapped the lambda to do the wrapping with a RuntimeException as in:

toRuntimeException( () -> new FileReader(file))

If it works you might get your code brevity back without your changes being necessary.

[davidmoten]

ah I just looked up java 8 lambdas and checked exceptions and I see my suggestion has no legs

[davidmoten]

Righto so I've tested the handling of lambdas and checked exceptions in java 8 and I can see this is a handy utility. It's a really interesting idea to then extend FuncN from UnsafeFuncN and I can see this would work. The more extreme implementation would be to add throws Exception to the definition of FuncN. Perhaps the enforced try catch in writing Operators that call FuncN will be worth the abbreviation for rxjava users. What would steer us away from this?

My only concern then is really the name because Funcs are inherently unsafe as there is nothing in the contract for a Func that says it can't throw a RuntimeException or Error. The alternative is something yuk like FuncCanThrowCheckedException.

[abersnaze]

How about CheckedFunc? I agree that I would like to see CheckedFunc used in core where ever an RuntimeException from a Func is caught and pushed down to onError. The reasoning is that if the implementation is already wrapping calls with a try/catch then let the Func throw whatever it wants.

[davidmoten]

Do you see an impediment to changing the signature of FuncN to include throws Exception?

[abersnaze]

Adding to FuncN directly would be too much. It forces operator implementations to always wrap exceptions even if they don't care about propagating RuntimeExceptions up the call stack.

[davidmoten]

there's the tradeoff I suppose between operator implentations and users using java 8 lambdas with rx operators and catching exceptions. In theory there'd be more of the latter right?

[davidmoten]

I'm thinking about Observable.map() in particular and the plethora of java methods that throw checked exceptions. Would be nice to make lambda usage cleaner.

[abersnaze]

The map operator explicit does a try catch around the Func1 call so that would be a candidate for switching to CheckedFunc1.

[davidmoten]

if we did map() I'd be tempted to do it everywhere. Might have to do an inventory of where Func is used in the Operators