-
Type:
Bug
-
Resolution: Fixed
-
Priority:
P3
-
Affects Version/s: None
-
Component/s: security-libs
-
b35
-
generic
-
Not verified
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8208982 | 8u201 | Sean Coffey | P3 | Resolved | Fixed | b01 |
| JDK-8201541 | 8u192 | Sean Coffey | P3 | Resolved | Fixed | b03 |
| JDK-8216885 | emb-8u201 | Sean Coffey | P3 | Resolved | Fixed | master |
end users get confused when they see exception stacks printed in debug mode from JDK classes. Some equate it to a problem in the JDK libs.
example code :
632 KeyStore keyStore = null;
633 try {
634 keyStore = PolicyUtil.getKeyStore
635 (policy,
636 pp.getKeyStoreUrl(),
637 pp.getKeyStoreType(),
638 pp.getKeyStoreProvider(),
639 pp.getStorePassURL(),
640 debug);
641 } catch (Exception e) {
642 // ignore, treat it like we have no keystore
643 if (debug != null) {
644 e.printStackTrace();
645 }
646 }
We should be more clear and perhaps prepend such traces with a clue like "Running in debug mode and printing this stack trace for reference…"
example code :
632 KeyStore keyStore = null;
633 try {
634 keyStore = PolicyUtil.getKeyStore
635 (policy,
636 pp.getKeyStoreUrl(),
637 pp.getKeyStoreType(),
638 pp.getKeyStoreProvider(),
639 pp.getStorePassURL(),
640 debug);
641 } catch (Exception e) {
642 // ignore, treat it like we have no keystore
643 if (debug != null) {
644 e.printStackTrace();
645 }
646 }
We should be more clear and perhaps prepend such traces with a clue like "Running in debug mode and printing this stack trace for reference…"
- backported by
-
JDK-8201541 Debug exception stacks should be clearer
-
- Resolved
-
-
JDK-8208982 Debug exception stacks should be clearer
-
- Resolved
-
-
JDK-8216885 Debug exception stacks should be clearer
-
- Resolved
-