juliuszsompolski commented on PR #48037: URL: https://github.com/apache/spark/pull/48037#issuecomment-2483100505
@yaooqinn @cloud-fan My intention here was that for debuggability, the user may need both the stack trace of the error where it originally happened (as stored in the Try and what Try normally returns), and the current stack trace when the error is "retriggered" by accessing the Try again. The two suppressed exceptions are needed for that: `TRY_WITH_CALLER_STACKTRACE_FULL_STACKTRACE` is the full original stacktrace when the stuff inside the Try was actually executed. `TRY_WITH_CALLER_STACKTRACE_TRY_STACKTRACE` is a prefix of the stack trace that is under `doTryWithCallerStacktrace` of the caller, which is needed so that `getTryWithCallerStacktrace` could stitch together the stack trace of the new caller with the original caller. I initially made it find `doTryWithCallerStacktrace` in there, but that doesn't work in recursive situations like is actually the case here. `TRY_WITH_CALLER_STACKTRACE_TRY_STACKTRACE` does not need to be visible and could be hidden... Maybe the `val fullEx = new Exception(TRY_WITH_CALLER_STACKTRACE_FULL_STACKTRACE)` instead of being a generic Exception, could be a special exception type that just holds the length of that prefix. Let me do that. -- 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. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
