Welcome back to my series of blogs that collect some tutorial resources about game music middleware for the game music composer. I had initially intended to publish two blog entries on this subject, focusing on the most popular audio middleware solutions: Wwise and FMOD. However, since the Fabric audio middleware has been making such a splash in […]
Tag Archives: Fabric
Have you ever found yourself in the process of try to understand how come something very simple is not working?
You are writing code in any well known context and for whatever reason it’s not working. And you trust your platform, so you carefully read all the logs that you have.
And still you have no clue why something is not behaving like expected.
Usually, what I do next, if I am lucky enough to be working on an Open Source project, is start reading the code.
That many times works; but almost always you haven’t written that code; and you don’t know the product that well. So, yeah, you see which variable are in the context. You haveno clue about their possible values and what’s worse you have no idea where or even worse, when, those values were created.
At this point, what I usually do is to connect with a debugger. I will never remember the JVM parameters a java process needs to allow debugging, but I know that I have those written somewhere. And modern IDEs suggest me those, so it’s not a big pain connecting remotely to a complex application server.
Okay, we are connected. We can place a breakpoint not far from the section we consider important and step trough the code. Eventually adding more brakpoint.
The IDE variables view allows us to see the values of the variables in contexts. We can even browse the whole object tree and invoke snippet of code, useful in case the plain memory state of an object doesn’t really gives the precise information that we need(imagine you want to format a Date or filter a collection).
We have all the instruments but… this is a slow process.
Each time I stop at a specific breakpoint I have to manually browse the variables. I know, we can improve the situation with watched variables, that stick on top of the overview window and give you a quick look at what you have already identified as important.
But I personally find that watches makes sense only if you have a very small set of variables: since they all share the same namespace, you end up with many values unset that just distract the eye, when you are not in a scope that sees those variables.
I have recently learnt a trick to improve these workflows that I want to share with you in case you don’t know it yet:
IntelliJ and, with a smart trick even Eclipse, allow you to add print statements when you pass through a breakpoint. If you combine this with preventing the breakpoint to pause, you have a nice way to augment the code you are debugging with log invocations.
For IntelliJ check here: http://www.jetbrains.com/idea/webhelp/enabling-disabling-and-removing-breakpoints.html