Provide more descriptive exception throwing in Compressor.java

[laura_]

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.

[Adam Peller]

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?

[Adam Peller]

so I don't think we should be able to reach the default case anymore. please re-open if this is still a problem