morhidi commented on PR #409: URL: https://github.com/apache/flink-kubernetes-operator/pull/409#issuecomment-1289657005
> @morhidi > > Thanks for the feedback and sharing your test result: > > > It resulted in an string, that might not be a valid JSON: > > I will do some testing on this and validate the final JSON that's included in the CR field. > > > Another thing that I found is the structure of the stacktrace probably too verbose: > > Yup, it does contain several metadata we might not need like "classLoaderName", "nativeMethod". An alternative that I am considering is to store the stackTrace as a more compact List generated from ExceptionUtils.getStackFrames (https://commons.apache.org/proper/commons-lang/javadocs/api-3.1/org/apache/commons/lang3/exception/ExceptionUtils.html#getStackFrames(java.lang.Throwable)) > > However, the downside of this is each stackFrame is a String, so it's a bit more work to figure out which method/file the stackFrame is called from. Any thoughts on which one's more suited for our needs? We might not need the stack trace in a structured format. Maybe just dump it as a string: ``` public static ExceptionDetail convertFromThrowable(Throwable t) { ExceptionDetail exceptionDetail = new ExceptionDetail(); exceptionDetail.setMessage(t.toString()); exceptionDetail.setRootCauseMessage(Throwables.getRootCause(t).toString()); exceptionDetail.setStacktrace(Throwables.getStackTraceAsString(t)); return exceptionDetail; } ``` Even if the root cause is not in the first cause. We would still find it I guess in the stack trace. -- 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: issues-unsubscr...@flink.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
