highlights a broader issue that's really outside the parser, we do a lot of "log and throw" sequences that repeat error logging at different layers but also log the exception that's rethrown, so we get a lot of redundant stack traces in the log.
I think the best choices are either to just elide the stacks at the lower layers that rethrow or change those logs to TRACE. For now I lean to the former.
Cleaned java-support based on regex "(\s*)log\.(.+)\n(\s*)throw" to find adjacent log/throw combinations.
Code will log the message if it subsequently throws a nested exception but not log the exception stack also.
Scott CantorOctober 24, 2018 at 5:00 PM
For future review, the DataSealer class in java-support has a lot of log and throw patterns. I think a lot of its callers suppress the exception, but the logging should be shunted up to those layers.
highlights a broader issue that's really outside the parser, we do a lot of "log and throw" sequences that repeat error logging at different layers but also log the exception that's rethrown, so we get a lot of redundant stack traces in the log.
I think the best choices are either to just elide the stacks at the lower layers that rethrow or change those logs to TRACE. For now I lean to the former.