'public static final' exceptions render stack trace useless

[miguelnmiranda]

In ConnectionPoolImpl.java PoolExhaustedException is 'stored' as a static final field.

public static final PoolExhaustedException POOL_EXHAUSTED_EXCEPTION = new PoolExhaustedException("Rx Connection Pool exhausted.");

This means that the stack trace displayed when you throw the exception refers to when ConnectionPoolImpl was first instantiated and not to the actual occurrence of the exception.
Is this a consequence of using Rx? Is there a way of getting more info around the state of the system when the exception occurred?

[NiteshKant]

@miguelnmiranda It isn't really a consequence of using Rx but the validity/usefulness of stacktrace in an asynchronous application and (possibly premature) optimization of reducing the overhead of creating a stacktrace when it has limited meaning.

Is there a way of getting more info around the state of the system when the exception occurred?

What other information are you looking for?

[miguelnmiranda]

@NiteshKant You are right, the meaning of a stack trace in an asynchronous application is very limited.
And my question was put out there out of frustration for not having any context of what the system looked like when the exception was 'thrown'.

What information is relevant really depends on the context. On my case it end up being a memory problem, or lack of it. But what bothered me at the time was that although the rest of the application I am working in is asynchronous it is structured in a different way where stack traces still makes some sense, and so when debugging your mindset is.. lets follow that! making us believe POOL_EXHAUSTED_EXCEPTION was an initialisation problem. Only after looking into RxNetty source code we realised that assumption was wrong.

Yours is a tricky question. Having a mechanism that would allow to decide what you want to see when such an exceptional event occurs would be nice. That being said, what is relevant will vary, and throwing exceptions might make sense in cases where you have a considerable amount of logic inside an event manipulator.

[NiteshKant]

@miguelnmiranda I will change this instance of cached exception to be created on demand. I agree it is misleading, whenever caching exception (when required), the stacktraces should atleast be truncated so that it is not confusing.