zentol commented on pull request #12392: URL: https://github.com/apache/flink/pull/12392#issuecomment-639095073
> I think the PR goes a bit in a different direction than I intended it to go initially. Yes that is true, but I feel like this approach is more universal. It pretty much _solves_ the problem. You can have a chain of 20 exceptions and the result would still be readable. We can (and should) go around and remove some of the re-wrapping, but my concern is that these are very limited in scope. You get rid of some small thing here and there, but the exception trace can still blow up. And going through all the code-paths in search for small optimization opportunities sounds rather time intensive; time which we don't have right now. > Trying to filter out StackTraceElement coming from CompletableFuture since they add often only noise. We can _probably_ do this; we also have to account for java 11 since the stack trace element will likely have a `java/base` prefix (but this isn't too difficult). I guess this would be less invasive than the current approach (but also less powerful). Or do you want this to be done everywhere (also in logs)? They are also mostly noise in the logs after all. But then we're basically talking about stripping execution exceptions wherever possible, which has similar problems as the re-wrapping stuff. Lots of places to check, tiny individual pay off, easy to re-introduce. > Hiding the client side stack traces. You do want client-side stacktraces to some degree, specifically when user-code is involved. In the example above in the PR description, this line should be present in all cases, because the user should have the information on what line of his code resulted in an error: ``` at org.apache.flink.streaming.examples.wordcount.WordCount.main(WordCount.java:101) ``` This makes this a bit tricky in regards to where you draw the line; hence why I was conservative on the client-side. The reconstructing part...well it would be neat but this could only work if there were an well-defined format for stacktraces, and I don't think there is. We currently format exceptions as a single string, and rebuilding the stack trace element could fail in weird ways if you have unusual exceptions (e.g., containing blank lines). In fact our current client exceptions are an excellent example for being unusual. ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org
