I still think crypto should do no logging at all, but propagate errors using exceptions. Higher level application code may catch those exceptions and implement the desired recovery routines:
- show a message to the user - Add the problem to an admin dash board - try a different crypto provider - ... - write something to a log Just writing to a log in case of error is bad practice IMHO. In the case of crypto we even have silent failure. Take for example CryptoCipherFactory.getInstance: the users specifies some classes which get loaded via reflection. In case something goes wrong, we log an error and continue. If we can not load any class, we just fallback to JceCipher. Let's hope our users have their logging set up properly or this will cause headaches... Benedikt sebb <seb...@gmail.com> schrieb am Sa., 11. Juni 2016 um 11:00: > On 11 June 2016 at 06:34, Ralph Goers <ralph.go...@dslextreme.com> wrote: > > > >> On Jun 10, 2016, at 2:56 PM, Torsten Curdt <tcu...@vafer.org> wrote: > >> > >>> Matt, there is a big difference between printing the stack trace and > >>> walking it to find the info. printing it on every debug call would be > >>> insane. > >>> > >> > >> Why would anyone want to do that? > >> > >> > https://docs.oracle.com/javase/7/docs/api/java/lang/StackTraceElement.html > >> > >> > >> And how do you think the logging frameworks get that kind of > information? :) > > > > I think you missed Sebb’s suggestion of having the debug method call > printStackTrace(). > > I was just pointing out that using a shared debug method does not lose > the original caller information, as it can be derived from the call > stack. > I was not suggesting that anyone would actually use that code. > > > Ralph > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
