Skip to content
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.

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

[3.x] RxJavaAssemblyTracking stack trace is not printed #76

Closed
piomar123 opened this issue Aug 17, 2020 · 6 comments
Closed

[3.x] RxJavaAssemblyTracking stack trace is not printed #76

piomar123 opened this issue Aug 17, 2020 · 6 comments

Comments

@piomar123
Copy link
Contributor

My test code:

package me.piomar.dataflow;

import java.util.List;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import hu.akarnokd.rxjava3.debug.RxJavaAssemblyTracking;
import io.reactivex.rxjava3.core.Flowable;
import io.reactivex.rxjava3.schedulers.Schedulers;

public class RxErrorApp {

    private static final Logger LOGGER = LoggerFactory.getLogger(RxErrorApp.class);

    public static void main(String[] args) {
        LOGGER.info("App start");
        RxJavaAssemblyTracking.enable();

        List<String> list = Flowable.just("a", "b", "c")
                                    .observeOn(Schedulers.computation())
                                    .map(RxErrorApp::bang)
                                    .toList()
                                    .blockingGet();
        LOGGER.info("Result: {}", list);
    }

    private static String bang(String input) {
        throw new IllegalStateException("bang");
    }
}

The result in console:

Exception in thread "main" java.lang.IllegalStateException: bang
	at me.piomar.dataflow.RxErrorApp.bang(RxErrorApp.java:29)
	at io.reactivex.rxjava3.internal.operators.flowable.FlowableMap$MapSubscriber.onNext(FlowableMap.java:64)
	at hu.akarnokd.rxjava3.debug.FlowableOnAssembly$OnAssemblySubscriber.onNext(FlowableOnAssembly.java:61)
	at io.reactivex.rxjava3.internal.operators.flowable.FlowableObserveOn$ObserveOnSubscriber.runSync(FlowableObserveOn.java:337)
	at io.reactivex.rxjava3.internal.operators.flowable.FlowableObserveOn$BaseObserveOnSubscriber.run(FlowableObserveOn.java:174)
	at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.run(ScheduledRunnable.java:65)
	at io.reactivex.rxjava3.internal.schedulers.ScheduledRunnable.call(ScheduledRunnable.java:56)
	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
	at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
	at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: hu.akarnokd.rxjava3.debug.RxJavaAssemblyException
Caused by: hu.akarnokd.rxjava3.debug.RxJavaAssemblyException

As it can be seen, there is no stack trace printed inside RxJavaAssemblyException. I'm using OpenJDK11, compiling to Java 8 (tested on JDK8 with same result). During debug, it can be seen that there is String RxJavaAssemblyException.stacktrace field which has been filled properly but seems it's not used anywhere.

Maven dependencies:

        <dependency>
            <groupId>com.github.akarnokd</groupId>
            <artifactId>rxjava3-extensions</artifactId>
            <version>3.0.0</version>
        </dependency>
        <dependency>
            <groupId>io.reactivex.rxjava3</groupId>
            <artifactId>rxjava</artifactId>
            <version>3.0.5</version>
        </dependency>
@akarnokd
Copy link
Owner

@piomar123
Copy link
Contributor Author

I noticed it after deeper debugging. What about setting message field or overriding getMessage()?
This would result in printing the stack trace without the need to catch and look for the nested assembly exception.

@akarnokd
Copy link
Owner

I don't remember exactly why it doesn't do it, but most likely due to it breaking IDE stacktrace displaying.

@piomar123
Copy link
Contributor Author

Do you remember which IDE could that be? In IntelliJ, printing it as an exception message works well.

@akarnokd
Copy link
Owner

Eclipse had certainly trouble with it. It is the very same situation as with ReactiveX/RxJava#6748 where the exception has to be carefully re-engineered.

You are welcome to try modifying the class and see if it works in Eclipse and IntelliJ as you'd expect.

@akarnokd
Copy link
Owner

Closing via #77.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants