Opened 12 years ago
Closed 11 years ago
#9288 closed defect (wontfix)
Provide more descriptive exception throwing in Compressor.java
Reported by: | laura_ | Owned by: | alex |
---|---|---|---|
Priority: | high | Milestone: | tbd |
Component: | ShrinkSafe | Version: | 1.3.1 |
Keywords: | Cc: | Richard Backhouse | |
Blocked By: | Blocking: |
Description
It's possible for Compressor.java to fail without providing any debugging information in the RuntimeException? that's thrown. I looked into this, and traced it to line 556:
... case Token.XMLATTR:
result.append('@'); break;
default:
If we don't know how to decompile it, raise an exception.
throw new RuntimeException?();
}
It would be awesome if that RuntimeException? included some more information. Because in our case, a developer had checked-in a stray 'debugger;' keyword into a JS file, and it caused the build to mysteriously fail. It took hours to slowly track down exactly what line of the JS was causing the problem.
Change History (3)
comment:1 Changed 12 years ago by
Cc: | Richard Backhouse added |
---|
comment:2 Changed 12 years ago by
comment:3 Changed 11 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
so I don't think we should be able to reach the default case anymore. please re-open if this is still a problem
debugger statement problem addressed in #9444. If we have a complete mapping of tokens in this switch (do we now?) wouldn't it be impossible to reach this statement? Is there any meaningful information we can easily give besides raw token information?