Skip to content

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

Description

@piomar123

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>

Activity

  1. akarnokd commented on Aug 17, 2020

    @akarnokd
    Owner
  2. piomar123 commented on Aug 17, 2020

    @piomar123
    ContributorAuthor

    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.

  3. akarnokd commented on Aug 17, 2020

    @akarnokd
    Owner

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

  4. piomar123 commented on Aug 17, 2020

    @piomar123
    ContributorAuthor

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

  5. akarnokd commented on Aug 18, 2020

    @akarnokd
    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.

  6. akarnokd commented on Sep 23, 2020

    @akarnokd
    Owner

    Closing via #77.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions