| Summary: | [Progress] Be more resilient to null args in StatusLine's progress monitor | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Nick Edgar <n.a.edgar> | ||||
| Component: | UI | Assignee: | Tod Creasey <Tod_Creasey> | ||||
| Status: | VERIFIED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | john.arthorne, Tod_Creasey | ||||
| Version: | 3.2 | Keywords: | helpwanted | ||||
| Target Milestone: | 3.4 M6 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
Created attachment 91014 [details]
Proposal patch
This is a proposal patch. It throws a null-pointer exception if the string parameter is null. The other possible solution could be to ignore such strings.
But I think it's better to inform instantly about the error.
As we accept null for beginTask (we convert it to an empty String) we should do the same here. Generally throwing a RuntimeException should only be done for catastrophic failures. Fixed in build >20080304 Verified in I20080323-2000 Tod, did we use this patch in the end? No we didn't - see comment #2. I went for a solution that did not throw an NPE. |
3.2 In an editor's save method, do the following with the progress monitor: monitor.setTaskName(null); monitor.subTask("foo"); It fails with an NPE on the second line of subTask, which is: if (fTaskName.length() == 0) { Although IProgressMonitor is not spec'ed to accept null, several clients do pass null (e.g. Workspace.run, see bug 161464). StatusLine protects itself against null in beginTask, and should probably also do so in setTaskName and subTask.