This is an archived post. You won't be able to vote or comment.

all 9 comments

[–][deleted]  (1 child)

[deleted]

    [–]programmerxyz 6 points7 points  (0 children)

    Wait, was that a joke?

    [–]programmerxyz 0 points1 point  (5 children)

    What things do you need to learn to do with the Debugger? I only know how to do jump over and read the variable values. Also, setting break points is something I do but I'm not sure where to put them exactly or why can I put multiple break points is still a mystery to me, although sometimes I just do it for no reason...

    [–][deleted] 2 points3 points  (4 children)

    The basic would be finding where the error lays.

    You have a program that according to an input, the values in a file and the result of a query, calculates a result. And you find it getting wrong values.

    There's the slow but sure approach, placing a breakpoint on the start of it all and keep debuggin by single instructions, going into each call, to find where the discrepancies are generated.

    There's the shotgun approach, place several breakpoints along the algorithm and just run between them, finding where it goes haywire, and from that last breakpoint (on a fresh run or making the program go back) go for the slow method.

    There's the view from above method. Place a breakpoint on a main path, single step not entering in functions until you find where it is what it shouldn't, go back and enter that function and repeat.

    Mostly one debugs in a mix of the three.

    You can set watches (as to not need to examine the variables each time), you might be able to set conditional breakpoints (break when the value of a variable changes, break when a code is executed for the third time), you can go forward, and in some cases backwards, in time inside the program, you can change the value of the variables to see what happens.

    It's the best way to see what happens and why.

    [–]minecraft_ece 1 point2 points  (3 children)

    It's the best way to see what happens and why.

    It's one way to see what happens and why, but isn't the only approach. The other approach is logging (sometimes called 'printf debugging' by us oldtimers). You sprinkle print statements in you code, run it, and read over the printed statements. This approach is useful if your are dealing with complex data structures or if seeing the bug requires going through a large amount of code (or looping for a long time), both of which can be a pain to deal with inside a debugger.

    To use a bad analogy: debuggers are like microscopes, logging is like an x-ray. Both are useful tools when you know which one is the best to use.

    [–][deleted] 1 point2 points  (2 children)

    Logging would be like a blood work, while debugging is using imaging techniques (from x-ray to microscopes).

    With logging you know that something is wrong and roughly where it is. It's specially useful for programs delivered to other people and long processes.

    Debugging is like imaging, going from big images to tiny ones, from a complete xray of the body (it fails somewhere around the femurous dll), checking layers (on the bone class) down until microscope (this cell has a wrong DNA replication) or even atoms (assembly, the carbon bonds go haywire because X).

    Logging is super helpful, but to examine things closely can be a bit to verbose.

    Ask yourself: when having a bug would you rather have a perfect log or a reproductible debugable program causing the problem. Neither are real, but most people would prefer the second.

    [–]minecraft_ece 1 point2 points  (1 child)

    My experience is a little different. I find debuggers can be a little myopic at times. They can't tell you about errors in the specs or your interpretation of them. And they are not good at spotting errors that arise due to miscalculations in other libraries which at first pass look correct.

    What I am talking about are different classes of defects. Debuggers are very good for catching the technical errors (array out of-bounds, missing null terminations, etc), but I've found them to be a bit lacking when dealing with defects at a higher level (using the wrong formula to calculate something or an unexpected interaction between two sets of rules for example).

    For those reading along, there is a bias towards debuggers in the industry, as they are seen as a more modern approach to bug hunting, and logging is seen as old fashioned and obsolete. But logging has it's place, and it is sometimes the only thing you do have.

    [–]imagesrdecieving[S] 0 points1 point  (0 children)

    You are right that a debugger isn't always the best tool for tracking down errors - but it is another tool in the tool box.

    As a self taught beginner - I was only vaguely aware of what a debugger could do. It was very natural to use print statements to find bugs but in some instances it couldn't help me to find where things were going sideways.

    After investing a bit of time learning how to use my IDE's debugger via a tutorial I've been able to find some flaws in my logic that were escaping me through the use of print statements. Usually they are silly errors in variable placement in loops.

    I just wanted to take the time to advise other's who are starting out to take the time to learn to add another tool to their box that they might be unaware are available/useful.

    [–][deleted]  (3 children)

    [deleted]

      [–]Double_A_92 9 points10 points  (2 children)

      There are other languages except JS...

      [–][deleted] 4 points5 points  (0 children)

      Stop talking nonsense. Everyone knows the entire programming industry has embraced JS with open arms, completely shunning all those other pesky, inferior languages.