Are you perhaps conflating two similar but different problems: 1. as a developer, it’s irritating how much stuff appears on the screen when I run tests; 2. as an administrator there is too much / too little / too much useless stuff in my logs.
I think we should just solve problem 1 for now. For 2, if we continue to write "No match found for function signature ABCDE(<NUMERIC>, <ANY>, <CHARACTER>)” to the log it’s not perfect but it’s better than nothing. Julian > On Aug 29, 2018, at 1:24 AM, Vladimir Sitnikov <[email protected]> > wrote: > >> 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
