Skip to main content

Quick Tip - SSJS Error line numbers

 Recently, I had to work on an app with a pretty huge server-side JavaScript codebase. Several developers with different levels of XPages knowledge worked on that project in the past, to the code is quite hard to follow. My suggestion to rewrite all the code to Java was not accepted, so we have to deal with SSJS for now.

One of the most annoying things, when you work with SSJS, is that in many cases you don't know where an error is happening. If you keep things simple and allow redirection to an error page (default or custom), you get a lot of information, and usually, you don't want to scare users with that or you may even want to do something useful in a catch block to recover from the problem. If the problem is thrown directly in the XPages JS engine, it's usually an InterpretException, which contains the context information, but if you have to deal with standard Java exceptions, you don't have it.

Imagine a simple scenario with a function in a ssjs lib.

When you run that code from a button, you get a lot of information

But when you start to add error handling, you won't get the line number, because the exception is java.lang.ArrayOufOfBoundsException. For example, typical SSJS error handling that I have seen in many places looks like this:

You must manually add some context information, so the logging method can give you at least some hint where the problem is coming from. If you work just with the exception, all you get is :

java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 2
    at java.util.Vector.get(
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

Today, I've found that there is a magic errorMsg variable that tells me more. It contains the message of the JavaScript exception, so you get the js line number. It does not tell you in which file, but it can still be helpful. So if the logError function looks like this (in real-world it should log somewhere, not just print to console):

You get the line number even when you use custom error handling:

Script interpreter error, line=4, col=27: Error calling method 'get(number)' on java class 'java.util.Vector'
ssjs_stuff lib - doStuff
Array index out of range: 2
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 2
at java.util.Vector.get(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

I was not able to get more context information from the JavaScript engine, but this already helps me a lot when looking at 1000s of lines of SSJS code. Another limitation is, that you probably can't get to the errorMsg from Java, so if you are logging directly to e.g. an OpenLog bean, you won't see this. Maybe HCL can do something about this and make this information available, e.g. in the requestScope.

I've tested this on 11.0.1, but I assume it exists in older versions too.


Popular posts from this blog

Microsoft Word black box in numbering issue

This is awkward post, primarily to save the solution for future me. I have seen many people mentioning this problem over years and as I've struggled with it several times, I needed to find final and permanent solution. All editions of Microsoft Word from time to time suffer from bug in numbering. Instead of a number, black box is displayed. Sometimes it happens right after document is opened, sometimes during editing. Probably some internal structure of document gets corrupted, so based on level of corruption, different fixes could help. Many of them are listed at I took different approach. Since docx is just standard zip package with xml files, I decided to try if I can fix it manually. And it worked. When I extracted the docx, there was file called numbering.xml in word folder. When I examined that file, I found strange se

Domino CI build with Jenkins and Docker

 I wanted to make this work for a very long time, but there were always some parts missing, so I could not get the full process running. Finally, the wait is over. The following paragraphs describe a way to build Notes/Domino apps automatically on a Jenkins server, allowing parallel builds and all "normal" continuous-integration behavior, without having to think too much about Domino specifics. The Problem Until now, I was running my automated builds of Domino apps using Jenkins in two ways: The official headless-designer way, where you need to pass special commands to Domino Designer and hope for the best as the Designer sometimes gets stuck. I have this wrapped inside a Jenkins pipeline, so I have some control and can e.g. avoid parallel builds by using locks on Jenkins, but still, sometimes it just dies. Some of my headless builds run for more than 30 minutes, so it's really hard to quickly spot an issue without actually connecting to the machi