Proposal: Plugin point to make fillInStacktrace() configurable for lifecycle boundary exceptions

[ZacSweers]

Exceptions aren't free. Currently we use exceptions to indicate lifecycle boundaries. Normally their trace would be helpful, but in some setups (such as our internal one), users track sources of exceptions in rx chains separately and just use the exception as a signal. Perhaps we can save a little performance by making a plugin hook to configure this. Then when receiving exceptions, traces would not be inspectable and the type would be your only clue.

This would be possible for pre-java8 too by overriding fillInStacktrace() and controlling behavior there. The default would be to remain enabled.

public class OutsideLifecycleException extends RuntimeException {

  public OutsideLifecycleException(String s) {
    super(s);
  }

  @Override public final synchronized Throwable fillInStackTrace() {
    if (AutoDisposePlugins.fillInStacktraces()) {
      return super.fillInStackTrace();
    } else {
      return this;
    }
  }
}

Questions:

• Should we?
• If no, why not?
• If yes
  • fillInStacktraces() method?
  • Static volatile boolean? (might not play well with lockdown())

[ZacSweers]

CC @malbano @AttwellBrian @tonycosentini, would like your thoughts on this

[ZacSweers]

and @Leland-Takamine

[Leland-Takamine]

Sounds reasonable - would be helpful to include a sample of the stacktrace before and after.