commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <>
Subject Re: [imaging] IMAGING-154 remove Debug class
Date Mon, 05 Feb 2018 13:47:17 GMT
On Mon, 5 Feb 2018 04:41:20 -0800, Otto Fowler wrote:
> Maybe Debug should be an interface ( perhaps with the current class 
> as the
> default implementation ) and be passed in optionally?
> On February 5, 2018 at 07:21:11, Bruno P. Kinoshita (
> wrote:
> Hello,
> If memory serves me well, some time ago we had a discussion around 
> sanselan
> & commons-imaging 1.0. One of the issues with commons-imaging 1.0 was 
> the
> Debug class.
> I finished the pull request, but Gilles raised an important point, 
> about
> discussing other alternatives first.
> Initially I am against logging in low level libraries, especially 
> commons
> components. But some time ago I had to debug TIFF issues in
> commons-imaging, and having the dump methods was a tremendous help.
> The issue is that some imaging algorithms/processing have a lot of
> variables that can be altered. And keeping an eye on all of them in 
> the
> debugger can be quite hard - though not impossible.
> So all in all, now I am more confident to proceed without the Debug 
> class.
> But some users could have a hard time investigating possible issues 
> in the
> library without seeing what's going on within the library.
> IMO, that could be solved with the logging/dump features... or 
> through a
> better design, especially around exception handling/throwing.

They are not necessarily exclusive options.
I mean: (intending on) good design is necessary but, if achieved,
it doesn't imply that logging is never necessary.

> The latter is
> my preferred approach. Instead of logging, I prefer - whenever 
> possible -
> that low level libraries throw exceptions and let me handle the 
> logging.

I'd like to recall that logging is a tool primarily for _users_:
it helps them see how their data is handled by "lower" layers.
[Even if the code is fine, some input data might make it seem to
behave strangely, and it is not necessarily the job of the library
developer to figure out how and why this happens. Moreover, in
those cases, a debugger is not always the most productive tool.]

> So, any thoughts? :) I'm +1 to remove the Debug class, and +0 to a 
> logging
> added to commons-imaging.

+1 to remove plain "println"
-0 to not provide an helpful alternative

In the end, the main developers' and support team should be free
to take the decision (IMHO), being fully aware that they deprive
themselves from potentially useful tools and additional help. :-)


> Bruno

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message