I don't have to explain the power of debugging and tracing thru the code. But it can happen only if you are executing your code locally. How can we debug a program which is executing in your customer's desktop? Logging is the solution. Although its not as powerful as debugging, it really helps in finding the bugs.
Eclipse provides a nice -debug command line option to switch on the logging mode. Shouldn't this option be -logging to avoid confusions? Don't ask me. I don't know :-P
The API Platform.inDebugMode() returns whether Eclipse is started with -debug or not. So in our code:
if(Platform.inDebugMode()){
System.out.println("My plugin is doing something");
}
When a customer has a bug, all he has to do is to start Eclipse with -debug option and send you the output. Simple? But the problem is your customer would have installed umpteen number of plugins and the log would literally be unreadable. How to enable logging for a specific plugin alone?
The .options file comes to rescue. This is a normal properties file, where you can specify the options including which plugins should be in debug mode and which are not. You can google for sample files.
Plugins are expected to look for this before printing the statement. So the above code should be:
if(Platform.inDebugMode() && Boolean.getBoolean(Platform.getDebugOption(Activator.PLUGIN_ID+"/debug"))){
System.out.println("My plugin is doing something");
}
Instead of repeating this if condition all over your plugin, you declare a field in your Activator and use it in other places:
public boolean inDebugMode = Platform.inDebugMode() && Boolean.getBoolean(Platform.getDebugOption(Activator.PLUGIN_ID+"/debug"));
and use it other places:
void foo(){
if(Activator.getDefault().inDebugMode()){
// debug mode
}
}
Sep 7, 2007
Debug your app
Subscribe to:
Post Comments (Atom)

0 comments:
Post a Comment