Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing |
Summary: | [PATCH] Throw Java trace on JNI error | ||||||
---|---|---|---|---|---|---|---|
Product: | udk | Reporter: | geki <h.mth> | ||||
Component: | code | Assignee: | geki <h.mth> | ||||
Status: | CLOSED WONT_FIX | QA Contact: | issues@udk <issues> | ||||
Severity: | Trivial | ||||||
Priority: | P3 | CC: | issues | ||||
Version: | current | ||||||
Target Milestone: | --- | ||||||
Hardware: | PC | ||||||
OS: | Linux, all | ||||||
Issue Type: | PATCH | Latest Confirmation in: | --- | ||||
Developer Difficulty: | --- | ||||||
Attachments: |
|
Description
geki
2006-05-31 19:40:20 UTC
I do not like the idea of unconditionally polluting stderr (or whereever the JVM decides to print ExceptionDescribe). Better approaches IMO would be: - Either statically #ifdef OSL_DEBUG_LEVEL>0 so that it is only active in debug builds; - or some dynamic osl debug mechanism, based on environment variables etc. (which is not in place, however); - or obtaining information about the exception via JNI and putting that into the RuntimeException's string. I am against that debug-only enabled Java trace. Have a look at the thread: http://lists.ximian.com/pipermail/openoffice/2006-May/001826.html It would have saved me some time if there had been a trace from beginning. ;) So a more verbose RuntimeException is the only way I see. Still, it is just a Java trace like any other if some Java code fails. And I do not like to hide the traces. Makes debugging really hard. Well, just my thoughts. ;) KR->Gekl: The right approach is certainly, to add the description to the exception message. Polluting the console is _no_ option (just imagine everybody doing so ;-). KR->Geki: Please take this back ... Since this happens only with broken JVMs it is no real issue of OpenOffice.org. Closing as WONTFIX. Anyone having this kind of issue can apply the patch to see what is going on. Created attachment 39491 [details]
throw exception on jni error
closing... |