I’ve struggled quite a bit with Eclipse and progress-monitors to try to have good progressbars which report useful progress information to the user. Inevitably the code gets cluttered with lots of things like
if (monitor.isCancelled())
return;
...
lengthyMethodCall(monitor.newChild(10));
and all over the place I need to pass a IProgressMonitor as an argument to my methods. This is bad, for several reasons:
- The code gets cluttered with lots of code which is not relevant to what the function actually does.
- I need to manually guesstimate which parts of the code takes time, and which parts do not.
- It interacts badly with automated tests; where much of the information which goes into a progressbar instead should be logged for later inspection.
Is there a way out of this? Are there tools which can help me out with one or more of these problems? Should I be looking at Aspect-Oriented Programming tools, or are there other alternatives?
2
The code gets cluttered with lots of code which is not relevant to what the function actually does.
Sounds like Java run time exceptions. 🙂 I guess one way out of the IProgressMonitor mess is to wrap up all of your “batch” processing into Jobs (org.eclipse.core.runtime.jobs).
I need to manually guesstimate which parts of the code takes time, and which parts do not.
Not really. You can wrap any code in a Job. If it executes quickly, you won’t even see the progress monitor popup. If it takes time to process, then it should be a Job anyway.
It interacts badly with automated tests; where much of the information which goes into a progressbar instead should be logged for later inspection.
ratchet freak already answered this in his comment. You can write your own implementation of IProgressMonitor that logs the information you wish.
3
maybe you could annotate each method with custom annotation and then process those annotations.
or maybe you could log the last execution time of those methods and then estimate time based on that.
1