Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (753)
Games in Android Showcase (228)
games submitted by our members
Games in WIP (842)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Debugging, i'm doing it wrong?  (Read 3529 times)
0 Members and 1 Guest are viewing this topic.
Offline saucymeatman
« Posted 2013-11-20 01:30:04 »

When I write code, and it does not as expected, normally the first thing I do is review what I did last. Because that probably caused this unexpected result. Should this fail, and the problom persists, I have System.out.prinln's set up within the code at different points to tell what is getting run, and when, and (if applicable) what different propertys of different variables are at different times.

But, I know there are debugging tools available, I just dont know anything about them. Also I have no idea if others go through a simmilar problom when a program behaves unexpectidly.

What do you all do when something isnt working?
Offline Slyth2727
« Reply #1 - Posted 2013-11-20 01:36:14 »

Well I will usually check my data types first if I am dealing with numbers. An int can't hold everything.
If it obviously has something to do with a faulty argument I will start at the bottom of where it originated and work my way up the calls that the crash report informed me of. Eg, Main.loop() at 30, Entity.update() at 133, so on until I get to the topmost class.  Then I can figure out if I did anything wrong when making the original methods.
If I can tell it is related to my inheritance tree I go up as well.
Offline wessles
« Reply #2 - Posted 2013-11-20 03:50:14 »

Sorry to say that there is no proven way to debug stuffs. It is something that you pick up over time. Even the big time pro's will make simple mistakes. It is not something that you will cure by adopting a different method, but by putting the time and effort into finding the problem, and trying not to make the mistake again. After all, problem solving is 2/3 the job! Wink
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline philfrei
« Reply #3 - Posted 2013-11-20 05:31:12 »

Do you use an IDE? Eclipse, NetBeans, IntelliJ all have step debuggers that allow you to stop at a break point and inspect the values in variables. If you haven't ever used this technique, it would be a good idea to give it a try.

Debugging is always a problem. I use the System.out.println() method a lot, but occasionally use the step debugger, too. Also, it is helpful to have a tests written that assert things you expect to be true. In my experience, this pays off when it comes time to track things down. The most annoying thing in the world though is to write a test that is itself buggy.  Tongue

Writing code in small steps and checking that it is behaving correctly, I also find that helpful. I try to resist writing a lot of changes at once. But sometimes a person gets on a "roll" and in the process of many changes, something bizarre or unexpected happens and the next thing you know 45 minutes (or worse) goes out the window because of some dumb typo that would have been caught almost immediately if one had been doing more checking and testing along the way.

An author like Martin Fowler might be a good bet as a source of explanations or tutorials on how to write tests.

music and music apps:
Offline Jeremy
« Reply #4 - Posted 2013-11-20 06:10:42 »

If an exception is thrown just look at the call-stack.

If you get unexpected results, you should know the method that causes those results to be formed (at some level in the call hierarchy). Put a break-point there and step through them line by line. Whenever you're about to enter a method, check that it performs its task correctly by examining the arguments and the return value (you don't need to step into it.)

The best system is to individually push all your changes that are testable (when your project gets large) to a repository. Then you can easily apply a diff on the code to see where you went wrong. I don't follow this advice often and just push large chunks of tested changes at a time just because I am lazy but it could save you a lot of head-aches in the future. If I were working for an employer it is definitely something I would try to do.

JevaEngine, Latest Playthrough (This demo is networked with a centralized server model)
Offline xsvenson
« Reply #5 - Posted 2013-11-20 09:24:06 »

I use pretty much exclusively the debugger. It's one of the awesomost tools on jvm (that and the profiler).
However, debugger might not always be the best help, for example complex multi-threading systems, where pausing a thread by a debugger might make the other threads work as expected. In those cases logging is Your best friend, a sysout is a bit less. Note that sysout is synchronized, which means it affects Your threads if You sysout often. Async logging has not that blocking behavior, in addition it can be directed to sysout, if You really need it.

The idea of the debugger is, that it given a source code line, it shows the current memory snapshot. This means, You can run Your code line by line and see the changes the code makes. Also, there are possibilities like watching a variable and catching the point where it changes value (very helpful when You have a ghost messing up Your states). Also, the debbuger works as client-server system, this means You can run a debugger in systems outside of Your current machine. For example, web application (test) servers (I don't recommend it on live systems, that's... just no ), start the server in debug mode and just connect to it with Your fav IDE. Works even the other way around. (Depending on the settings) start Your IDE and make the server connect to You. This, of course, depends on how the network is setup etc.

So my advice is, teach Yourself how to use the debugger asap, the benefits are immense.

“The First Rule of Program Optimization: Don't do it. The Second Rule of Program Optimization (for experts only!): Don't do it yet.” - Michael A. Jackson
Offline Opiop
« Reply #6 - Posted 2013-11-20 11:51:30 »

Off topic but: I always thought it was funny that in coding a lot of your time isn't actually spent creating the program, but looking for bugs. That's just somehow odd to me, its like your fixing your work more than you're actually creating it.
Offline philfrei
« Reply #7 - Posted 2013-11-20 18:00:16 »

Off topic but: I always thought it was funny that in coding a lot of your time isn't actually spent creating the program, but looking for bugs. That's just somehow odd to me, its like your fixing your work more than you're actually creating it.

And despite knowing this, many coders still tend to write in ways that emphasize just getting new code written over writing code that is set up to make it easier and quicker to catch and fix bugs.

music and music apps:
Offline ctomni231

JGO Wizard

Medals: 99
Projects: 1
Exp: 7 years

Not a glitch. Just have a lil' pixelexia...

« Reply #8 - Posted 2013-11-20 21:47:23 »

Off topic but: I always thought it was funny that in coding a lot of your time isn't actually spent creating the program, but looking for bugs. That's just somehow odd to me, its like your fixing your work more than you're actually creating it.
And despite knowing this, many coders still tend to write in ways that emphasize just getting new code written over writing code that is set up to make it easier and quicker to catch and fix bugs.

I had a huge discussion over this exact same issue just a few days ago. I remember when going through coding classes, many teachers would tell me to "code defensively". I think I have a grasp now on what they were trying to accomplish. They were trying to prevent code from reaching this state in where you cause 2 new bugs for each new piece of code you write. However, these techniques probably aren't common knowledge, so I'll just lay them out here...

Code in small pieces

Try to keep away from lengthy code sessions. Not only is it a risk, (we can lose all of our work if the power goes out or you accidently click close), but it also increases chances for errors and makes it harder to trace bugs. Save often and compile often.

Comment more

As programmers, we usually don't comment enough. The problem isn't apparent when you are working on something daily, but when you come back to it after a while you almost get to the point where you have to re-learn your own code. The worst side-effect about it is, you forget what features you already have. You can easily start creating bugs for no reason.

Write code legible

Keep the code organized and in modules if possible. It saves a lot of headache in the long run, and making it modular for large projects really gives programming a "tool set" feel. It feels good to be able to use code in multiple places. Disorganized code is a recipe for bugs.

Those techniques are good for prevention, but what about when I have errors anyway...

It depends on the bug. Usually, if I'm dealing with a logic error I always use the debugger or the JUnit tests to try and solve it. Sometimes you need to keep a good track of what your variables are doing to help you solve a problem. If I'm lazy and I think the logic error is in a specific spot, I'll use print statements. If the error has to do with performance, I always depend on the profiler. If the error is syntax, I just solely use the debugger.

Having a plan is always good for programming. Even with very high amounts of documentation, it is still very possible to have bugs. You have to actively watch over your code to make sure you aren't creating issues further up the chain. As said earlier in the thread, 2/3 of programming is just problem solving. (I guess the other 1/3 is creating the problems Tongue )

Offline cylab

JGO Kernel

Medals: 174

« Reply #9 - Posted 2013-11-21 13:01:48 »


but seriously.... USE THE DEBUGGER Wink

In all IDEs I know, using the debugger means:

- click in the column between your code and the line numbers to create a breakpoint at an interesting place
- start your program by clicking on the debug button instead of the run button
- your program will halt at the breakpoint, marking that line
- you get a panel with all variables and their values at the bottom

thats it. no need to hold you back. once you've found out about other possibilities like setting values of variables on-the-fly and even hot-exchanging code during your debug session, you'll ask yourself why oh why you ever even bothered writing System.out.println to debug something...

Mathias - I Know What [you] Did Last Summer!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline StrideColossus
« Reply #10 - Posted 2013-11-21 13:21:11 »

All of the above is excellent advice.

I'll add one thought that is a sort of combination of several of these suggestions: write unit-tests and step through them with the debugger.

Couple of reasons for doing this:

- A suite of unit-tests will trap a lot of dumb mistakes sooner rather than later.  As you say, new changes are often the source of bugs.

- Stepping through tests is a great to check that your code is really doing what you think it's doing at relatively little cost in terms of effort.

- I find a lot of bugs are relatively dumb mistakes on my part that can be easily hot-fixed in the debugger as you're testing.

Happy de-bugging.

- stride
Offline Riven

« JGO Overlord »

Medals: 1335
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #11 - Posted 2013-11-21 17:20:22 »

The problem with breakpoints is that your method may go bezerk at the 263rd invocation, due to a state caused by the 22nd invocation. With breakpoints you get a view of the current state of affairs, which is not always that valuable. Most of the time I use println to debug something, as it allows me to trace back how a certain state was reached, without having to step endlessly through the code. I just search the bulky logs.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline cylab

JGO Kernel

Medals: 174

« Reply #12 - Posted 2013-11-21 18:43:23 »

the problem with anything is that there always might be something that may not work sometimes...  Tongue

My answer was a bit coarse.

I just wanted to emphasis that trying to find a bug using a debugger first usually helps in the majority of cases. Depending on the nature of the problem, you sometimes need to log debug output, put in asserts, use conditional breakpoints, create isolated testcases, draw color markers in textures etc.

Mathias - I Know What [you] Did Last Summer!
Pages: [1]
  ignore  |  Print  

ivj94 (579 views)
2018-03-24 14:47:39

ivj94 (43 views)
2018-03-24 14:46:31

ivj94 (362 views)
2018-03-24 14:43:53

Solater (59 views)
2018-03-17 05:04:08

nelsongames (104 views)
2018-03-05 17:56:34

Gornova (138 views)
2018-03-02 22:15:33

buddyBro (681 views)
2018-02-28 16:59:18

buddyBro (89 views)
2018-02-28 16:45:17

xxMrPHDxx (491 views)
2017-12-31 17:17:51

xxMrPHDxx (727 views)
2017-12-31 17:15:51
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!