Skip to content

2.x: Evaluate Schedule initialization via Callable #4585

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 13 commits into from
Sep 26, 2016
Merged

2.x: Evaluate Schedule initialization via Callable #4585

Changes from 1 commit
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
0ab5956
Evaluate Schedule initialization via Callable
Sep 22, 2016
5112117
Clarify docs that Schedulers are initialized by the return value of t…
Sep 22, 2016
85e14a9
Enforce non-null Callable Scheduler and Scheduler
Sep 24, 2016
1303f47
Add remaining tests and tidy
Sep 24, 2016
e521926
Expand relevant Javadoc
Sep 24, 2016
9ccf4ed
Make error messages more consistent
Sep 24, 2016
38bb3c0
Correct Exception naming
Sep 24, 2016
174ce7a
Add test for Exception message to verify root cause
Sep 24, 2016
aeafcc7
Add tests for alternative initialization path
Sep 24, 2016
786090d
Simplify statement
Sep 24, 2016
c191e31
Use holder pattern for default Scheduler instances
Sep 24, 2016
fff28b2
Use correct scheduler when verifying reset
Sep 25, 2016
a273507
Make onInitHandler functions lazy and enforce non null.
Sep 25, 2016
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Make error messages more consistent
  • Loading branch information
Peter Tackage committed Sep 24, 2016
commit 9ccf4ed937ac6d6a3a23366f60440689323c0f6f
12 changes: 6 additions & 6 deletions src/main/java/io/reactivex/plugins/RxJavaPlugins.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -190,7 +190,7 @@ public static Function<Scheduler, Scheduler> getSingleSchedulerHandler() {
* @throws NullPointerException if the callable parameter or its result are null
*/
public static Scheduler initComputationScheduler(Callable<Scheduler> defaultScheduler) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should not it throw on a null callable? What's the point of calling with null?

Copy link
Contributor Author

@peter-tackage peter-tackage Sep 22, 2016 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was done for consistency with the existing expectations in RxJavaPluginsTest.clearIsPassthrough(), specifically:

assertNull(RxJavaPlugins.initComputationScheduler(null));
assertNull(RxJavaPlugins.initIoScheduler(null));
assertNull(RxJavaPlugins.initNewThreadScheduler(null));
assertNull(RxJavaPlugins.initSingleScheduler(null));

Should this be changed to only return null if the Callable returns null (and throw if the Callable itself is null)?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Null should not be allowed as a return value from the Callable nor from the init Function.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be a change, because previously the Scheduler value for RxJavaPlugins.init* was allowed to be null, as per - assertNull(RxJavaPlugins.initSingleScheduler(null));.

I will add an additional set of tests for the new behavior (something along the lines of assemblyHookCrashes).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

ObjectHelper.requireNonNull(defaultScheduler, "Scheduler Callable cannot be null.");
ObjectHelper.requireNonNull(defaultScheduler, "Scheduler Callable can't be null");
Function<Scheduler, Scheduler> f = onInitComputationHandler;
if (f == null) {
return call(defaultScheduler);
Expand All @@ -205,7 +205,7 @@ public static Scheduler initComputationScheduler(Callable<Scheduler> defaultSche
* @throws NullPointerException if the callable parameter or its result are null
*/
public static Scheduler initIoScheduler(Callable<Scheduler> defaultScheduler) {
ObjectHelper.requireNonNull(defaultScheduler, "Scheduler Callable cannot be null.");
ObjectHelper.requireNonNull(defaultScheduler, "Scheduler Callable can't be null");
Function<Scheduler, Scheduler> f = onInitIoHandler;
if (f == null) {
return call(defaultScheduler);
Expand All @@ -220,7 +220,7 @@ public static Scheduler initIoScheduler(Callable<Scheduler> defaultScheduler) {
* @throws NullPointerException if the callable parameter or its result are null
*/
public static Scheduler initNewThreadScheduler(Callable<Scheduler> defaultScheduler) {
ObjectHelper.requireNonNull(defaultScheduler, "Scheduler Callable cannot be null.");
ObjectHelper.requireNonNull(defaultScheduler, "Scheduler Callable can't be null");
Function<Scheduler, Scheduler> f = onInitNewThreadHandler;
if (f == null) {
return call(defaultScheduler);
Expand All @@ -235,7 +235,7 @@ public static Scheduler initNewThreadScheduler(Callable<Scheduler> defaultSchedu
* @throws NullPointerException if the callable parameter or its result are null
*/
public static Scheduler initSingleScheduler(Callable<Scheduler> defaultScheduler) {
ObjectHelper.requireNonNull(defaultScheduler, "Scheduler Callable cannot be null.");
ObjectHelper.requireNonNull(defaultScheduler, "Scheduler Callable can't be null");
Function<Scheduler, Scheduler> f = onInitSingleHandler;
if (f == null) {
return call(defaultScheduler);
Expand Down Expand Up @@ -957,7 +957,7 @@ static <T, R> R apply(Function<T, R> f, T t) {
static <T, R> R apply(Function<T, R> f, Callable<T> t) {
try {
T value = t.call();
ObjectHelper.requireNonNull(t, "Callable result cannot be null.");
ObjectHelper.requireNonNull(t, "Callable result can't be null");
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you mean to check value here instead of t

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also you could just T value = Object.requireNonNull(t.call(), "messge")

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, good find.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that would be better. I didn't notice the return value in the signature.

return f.apply(value);
} catch (Throwable ex) {
throw ExceptionHelper.wrapOrThrow(ex);
Expand Down Expand Up @@ -994,7 +994,7 @@ static <T, U, R> R apply(BiFunction<T, U, R> f, T t, U u) {
static <T> T call(Callable<T> t) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

inline this method?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what you mean. I've tried to be consistent with the abstraction of the similar apply method. Do you think that should change?

try {
T result = t.call();
ObjectHelper.requireNonNull(result, "Callable result cannot be null.");
ObjectHelper.requireNonNull(result, "Callable result can't be null");
return result;
} catch (Throwable ex) {
throw ExceptionHelper.wrapOrThrow(ex);
Expand Down