XPages: I need a full stacktrace

346 views Asked by At

Trying to debug an XPages application here. When there's a Java exception, XPages gives me a lot of lines in log.nsf and just when it gets interesting it says:

09/06/2015 17:32:53 HTTP JVM: ... 81 more

This is so annoying, to say the least The first real error is always in the bottom part of the stacktrace.

Is there a system parameter that I can set in order to get a full stacktrace?

Thanks!

The last part, from the log.nsf database:

09/06/2015 17:31:15   HTTP JVM: Caused by: 
09/06/2015 17:31:15   HTTP JVM: java.lang.NullPointerException
09/06/2015 17:31:15   HTTP JVM:     at org.openntf.domino.utils.DominoUtils.isHierarchicalName(DominoUtils.java:412)
09/06/2015 17:31:15   HTTP JVM:     at org.openntf.arpa.NamePartsMap.parse(NamePartsMap.java:545)
09/06/2015 17:31:15   HTTP JVM:     at org.openntf.arpa.NamePartsMap.parse(NamePartsMap.java:532)
09/06/2015 17:31:15   HTTP JVM:     at org.openntf.arpa.NamePartsMap.<init>(NamePartsMap.java:103)
09/06/2015 17:31:15   HTTP JVM:     at org.openntf.domino.impl.Name.parse(Name.java:1045)
09/06/2015 17:31:15   HTTP JVM:     at org.openntf.domino.impl.Name.parse(Name.java:1060)
09/06/2015 17:31:15   HTTP JVM:     at org.openntf.domino.impl.Name.getCommon(Name.java:593)
09/06/2015 17:31:15   HTTP JVM:     ... 81 more

Solved

    var author= doc.getItemValueString("Author");
    if(author) {
        var editor:NotesName= session.createName(author); 
        adoc.replaceItemValue("Editor", editor.getCommon());
    }

I added a simple test to verify that author isn't empty. The Author field used to be present in the document, and a getCommon on an empty NotesName seems to generate the exception.

3

There are 3 answers

6
Steve Zavocki On BEST ANSWER

I think that e.printStackTrace(); gives you the whole thing. You use this line stand alone. It can't be part of a System.out.println, which I tried to do once, although that is what it does essentially.

You would put this in your catch block. So the entire code would be:

catch (Exception e){
            e.printStackTrace();
        }

With that being said, I can't rememember a single time where anything useful is in those "81 more" lines of the stack trace. Just search for the "Caused by..."


As a general rule, you will want to surround your code in try/catch blocks even if they aren't manditory. It is generally considered better to use logging to trap errors than to write to the Notes log, using System.out.println and/or printStackTrace()

0
Sathish On

As per javadoc those lines will be present in the stacktrace itself.. See here: http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Throwable.html#printStackTrace()

Note the presence of lines containing the characters "...". These lines indicate that the remainder of the stack trace for this exception matches the indicated number of frames from the bottom of the stack trace of the exception that was caused by this exception (the "enclosing" exception). This shorthand can greatly reduce the length of the output in the common case where a wrapped exception is thrown from same method as the "causative exception" is caught

0
Paul Stephen Withers On

XPages OpenLog Logger (and the same code is also in OpenNTF Domino API) writes a full stack trace for errors to OpenLog. If you have a custom error page defined in the database, uncaught exceptions are also logged with the stack trace. (The custom error page is needed so the Render Response phase runs, albeit in a new page, which allows the code to create the log.)

It will also identify, if possible, the component that is triggering the error.