-Re: Review Request 20240: Follow-up KAFKA-1352: Standardize stack trace printing in logs
This is an automatically generated e-mail. To reply, visit:
(Updated April 11, 2014, 12:05 a.m.)
Review request for kafka.
Standardize stack trace printing in logs:
This this the criterion I followed whenever we need to log with a thrown exception:
1. No stack trace below WARN
2. For WARN,
a) Print stack trace when calling library functions (i.e. non-kafka functions) or we captured Throwable which could be various exception types.
b) Print e.toSting (e.Class.Name + ":" + e.Message) when we captured Throwable but we could be sure about possible exception types.
c) Only print e.Message otherwise.
3. For ERROR, always print stack trace.
Also there are some mis-use of swallow, which should only be used when "we do not throw more exceptions but just log in with stack trace in whole", but not "when we really do not care if it throw any exceptions".
Moving forward, I would like to suggest some exception handling manners:
1. Only capture Throwable when 1) calling a library function whose throwable exceptions are not defined clearly, or 2) if we REALLY want to "swallow" any exceptions thrown. In the second case, we should not any exceptions thrown.
2. For our own scala classes, specify possible checked kafka exceptions in the comments as often as possible (for java classes do that in signatures). And then whenever possible, case-enumerate all possible exceptions and just log their error messages.
3. Only re-throw the same/another exception after logging when the function needs a return value and the thrown exception cause it to not able to return anything. And in this case, throw a specific exception and capture it the caller without further double-logging.