Open blacelle opened 3 years ago
This is a valid issue. However we are not likely to do a large change to the repo at this point (which requires discussing and finding a somewhat better solution, rewrite the code generator, regenerate all the underlying code (all those FooInner
s)).
Develop focus is shifted to next generate SDK https://aka.ms/azsdk/java/mgmt (migration should be easy, though PagedList
is replaced by PagedIterable
), which now uses reactor as underlying async lib.
However the sync/async is designed similarly, as sync being a blocked wrapper over async operation.
A similar call of azure.resourceGroups().list().stream().count()
(note PagedIterable
will no longer send request if no element is consumed) give me this stack. At least this one gives me the location of the code (i.e. ManageResource.runSample(ManageResource.java:40)
).
com.azure.core.management.exception.ManagementException: ...
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:64)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:500)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:481)
at com.azure.core.http.rest.RestProxy.instantiateUnexpectedException(RestProxy.java:343)
at com.azure.core.http.rest.RestProxy.lambda$ensureExpectedStatus$5(RestProxy.java:382)
...
at io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:989)
at io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:832)
Suppressed: java.lang.Exception: #block terminated with an error
at reactor.core.publisher.BlockingSingleSubscriber.blockingGet(BlockingSingleSubscriber.java:99)
at reactor.core.publisher.Flux.blockLast(Flux.java:2519)
at com.azure.core.util.paging.ContinuablePagedByIteratorBase.requestPage(ContinuablePagedByIteratorBase.java:94)
at com.azure.core.util.paging.ContinuablePagedByItemIterable$ContinuablePagedByItemIterator.<init>(ContinuablePagedByItemIterable.java:50)
at com.azure.core.util.paging.ContinuablePagedByItemIterable.iterator(ContinuablePagedByItemIterable.java:37)
at java.base/java.lang.Iterable.spliterator(Iterable.java:101)
at com.azure.core.util.paging.ContinuablePagedIterable.stream(ContinuablePagedIterable.java:50)
at com.azure.resourcemanager.resources.fluentcore.utils.PagedConverter$PagedIterableImpl.stream(PagedConverter.java:200)
at com.azure.resourcemanager.resources.samples.ManageResource.runSample(ManageResource.java:40)
at com.azure.resourcemanager.samples.ResourceSampleTests.testManageResource(ResourceSampleTests.java:56)
Thanks @weidongxu-microsoft. In fact, I discovered this alternate Azure Management library very recently. The README for this repository indicates there is a more recent alternative. But it was not crystal-clear to myself. I interprete Try the Next-Generation Azure Management SDK for Java now
that current current repo is the next-generation, and I did not read the rest of the paragraph (too bad).
Would you mind making the point this library is kind of deprecated clearer? Deprecation is maybe too strong for now, but you get my point.
@blacelle
Well, it is not deprecated (yet). It is kind of in this state: if we have bug or improvement related to security, we fix here and on the new repo; if we have new feature or other improvement, we likely only put it in the new repo.
Is your feature request related to a problem? Please describe. In many places, any sort of exceptions is bubbled without a context, leaving the stack-trace reader with a partial stack difficult to process
Describe the solution you'd like I would like Exceptions to be properly chained, so that finally reported Exceptions holds a proper chain of Cause, enabling retracing the whole chain of calls.
Sorry for the quite long ticket while I suspect it may be rejected right-away, I tried to be quite exhaustive in my analysis.
Typically, I consider a piece of code like:
I end with a failure in ResourceGroupsInner:
This leads to stacks like:
My main issue here is that I capture an Exception is some sort of generic Exception handler (e.g. a Spring @ControllerAdvice). However, the stack does not even report my class having called
azure .resourceGroups().list()
.A richer stack would be available by wrapping the bubble-ed exception in ResourceGroupsInner.listSinglePageAsync :
However, this would not produce a full stack due to :
In my case, the stack looks like:
Hence, the calling thread own stack is not properly bubbled due to:
The questions of exception bubbling in Rxjava is regularly considered (e.g. https://github.com/ReactiveX/RxJava/issues/969).
However, blocking statements are considered inappropriate for production:
BlockingObservable:
Should I consider this as an issue in Rxjava BlockingObservable ? (i.e. BlockingObservable does not propagate properly exceptions from different threads, hence losing the stack for calling thread?)
Or should I consider this should be managed by calling libraries (here Azure libraries), to catch systematically such exceptions, and re-wrap them? However, this would lead to the inner exception to be be available directly (still being available through the chain of causes).
In the second case, it would lead in any sync call to something like:
ResourceGroupsInner: