This mostly applies to UnsafeArg, but maybe we could also add to SafeArg for consistency. The more probable scenario with SafeArg is a field that is too large/expensive to log.
+1 to also adding to SafeArg for lazy evaluation for perf concerns as I've seen a few internally. Would also allow cleansing for safe logging portion of object.
We may want to log an object with a sensitive field that should not be logged even under unsafe parameters (e.g. user credentials).
Rather than relying on the
toString()
implementation to remove the offending value, users should instead be able to write:This mostly applies to
UnsafeArg
, but maybe we could also add toSafeArg
for consistency. The more probable scenario with SafeArg is a field that is too large/expensive to log.