commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benedikt Ritter <brit...@apache.org>
Subject Re: [crypto] Logging dependency
Date Sat, 11 Jun 2016 09:17:03 GMT
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 <sebbaz@gmail.com> schrieb am Sa., 11. Juni 2016 um 11:00:

> On 11 June 2016 at 06:34, Ralph Goers <ralph.goers@dslextreme.com> wrote:
> >
> >> On Jun 10, 2016, at 2:56 PM, Torsten Curdt <tcurdt@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message