>A sql validation error when a statement is being prepared (say by a jdbc server) is really an error, and I think it should be logged.
Suppose there's an end-to-end data management system that happens to use Calcite. What action should system administrator take when the following error is printed in the log? org.apache.calcite.runtime.CalciteContextException: From line 1, column 17 to line 1, column 40: No match found for function signature ABCDE(<NUMERIC>, <ANY>, <CHARACTER>) Note: those error messages provide NO context on the stack trace. SQL is missing as well. Business level info (user name, transaction name, business action name) is missing as well. Note2: the application might HANDLE the error and issue an alternative query. For instance: if query fails, it might use different syntax. If query timeouts, the application might use alternative query. When that happens, the original "exception" is not an error. It must not be printed as error. How Calcite knows if application handles the error? Julian>Is there a way to achieve both of the above? I agree with your instinct that the tests are currently much too verbose. The point is it is not Calcite's business to identify if the error is SEVERE for application or not. Calcite throws the errors, and it makes very little reason to log "just messages". I have went though the same "ignorance-denying-despair-acceptance" route with silencing exceptions in https://github.com/pgjdbc/pgjdbc/pull/1187 The errors (and warnings) should be actionable. In other words, system administrator should be able to perform corrective actions. Logging all the CalciteExceptions provides no way to distinguish truly important stuff from "dev tracing". Note: there's always an option to enable TRACE logging level for CalciteException which will activate "automatic printing of all the errors with stacktraces". That might be useful for debugging/analyzing of bad system behavior, however it should be disabled by default. Vladimir
