I also kind of disagree with Tim about it un-usefulness of a debugger. You can achieve way more that just stepping through the code. You can even dynamically add debugging traces without needing to touch the code and this he forgets: you cannot add logging statements for code you cannot compile yourself such as the JVM for example or other Maven artifacts. Have a look as well at tools such JRebel and Yourkit. They are use cases where they help you to save a lot of time.
Cheers, JM On Thu, Aug 6, 2020 at 7:50 PM Matthias Bläsing <mblaes...@doppel-helix.eu> wrote: > Hi, > > I don't think debugging with logging/println statements and debugging > are either or. Both are approach that can be taken. > > HOWEVER, if you are new to programming, learn to use a debugger. While > there is learning involved and it is not always the right tool, having > it available is a great help. > > In a past job we had a central staging JavaEE server, that was used to > do QS testing with the end users. That server had the jpdw agent loaded > and at times it was invaluable to be able to just debug in the testing > system with the user reproducing his problem. > > With a debugger it is much easier to explorer the current runtime > environment and in contrast to logging statements, you don't need to > know what you want to know before it happens. > > Contrary to Tims reply a debugger does not require you to single step > through code. Line break points are pretty fast, method break points > are slower, but can be helpful to get to the offending code quickly. > > In the end the same advise as in many other cases in IT applies: > > - Know your tools (also the ones you may not like) > - Know when to use which tool > > Just a second perspective > > Matthias > > Am Donnerstag, den 06.08.2020, 03:12 -0400 schrieb Tim Boudreau: > > I've been developing NetBeans itself and plugins for it for 21 years now. > > In that time I have run a debugger against NetBeans maybe ONCE, to see if > > it worked. > > > > The startup time penalty, and the odds of winding up stepping through > code > > you actually need to see, rather than marching endlessly through > > java.util.Logger's source code and other irrelevant stuff, are > > infinitesimal. Debuggers are a great tool for debugging algorithms you > can > > isolate in a test or tiny application, or for learning how programs work > > when you're learning to program. As a tool for fixing things in huge > > applications with deep stacks, they're pretty much useless - way too much > > distracting noise and way to little signal. > > > > My suggestion is, learn to love logging statements and > > System.out.println(). You can isolate problems quite fast if you do a > sort > > of logging-binary-search - add a logging statement entering the code > where > > something goes wrong, and one at a point where that thing probably has > > already gone wrong. If that works as expected, add logging at the > midpoint > > between those two points. Still okay at the midpoint? Add one between > the > > middle and end - and so forth until you're on the line where things > really > > do go wrong (usually just narrowing down the scope lets you see it). > > > > Sorry to be a downer on debuggers, but I can count on one hand the number > > of times I have learned anything useful from a debugger, and all of those > > times I could have probably found it faster if I'd just read the code. > > > > -Tim > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > For additional commands, e-mail: dev-h...@netbeans.apache.org > > For further information about the NetBeans mailing lists, visit: > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > >
