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(Vector.java:753)
    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
java.lang.ArrayIndexOutOfBoundsException: Array index out of range: 2
at java.util.Vector.get(Vector.java:753)
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.

Comments

Popular posts from this blog

XPages Date Field Issue: Solving the One-Day Jump on Every Save

 A user reported a very strange issue - when a document with a date field is saved, it changes the value one day to the past. With every save. But only for some dates, not all. It turned out to be a mystery that goes deep into XPages and Notes/Java APIs. I've posted a sample on OpenNTF Discord and Serdar tried it on his server - no issue. But he uses the GMT zone and I have CET (Windows set to UTC+1 - Amsterdam, Berlin... to be precise). To cut it short, the issue is caused by daylight saving interpretation between Notes and Java. The date fields (because XPages have no notion of real date-only fields) are stored with 00:00 time component and for some dates the conversion back to Java Date resulted in 23:00 on the previous day. XPages that get the date component as String for the input field, which is then saved back as a previous day during document save. The app is full of date fields and I couldn't add custom logic to every save operation, so I tried to fix it at XPages conv...

HCL Domino 12.0.2, Engage 2022 and HCL Factory tour Milan

 I haven't published my recap after Engage this year and the recent HCL Factory tour in Milan is a great opportunity to write a summary about what's happening in HCL (mostly Domino) space. It's a mix of news about 12.0.2, future directions, and my impressions, so it can be a bit chaotic, but I got the impression that many people see it similarly.  Engage 2022 Engage 2022 was great (as always). I love the atmosphere in Brudges. I visited it once after Engage a few years ago and I was happy to come back. This was also the first time I had the opportunity to speak at Engage, which obviously made it a bit more stressful, but also more fun. Together with Domino Jams, HCL continued conversations with customers and partners about the future of their products at Engage. Many of these ideas were now discussed in greater detail in Milan, some of them were even demoed.  My main takeaways from Engage were: Nomad (web and mobile) are a great addition to Notes family Restyle is a great...

XPages EL/class-loader memory leak (now with solution)

 We have recently experienced OutOfMemory crashes of XPages app server. The server was recently upgraded to 12.0.1FP1, but we were getting some panic crashes in HTTP even before the upgrade (it was 9.0.1FP10). Our hopes were that the upgrade would stabilize the server, but it's not the case. At least now I start to see what's the problem.  update 8.12.2022 There were actually 3 different leaks. I have rewritten the article to be a bit more clear. I also re-run some of the tests on 9.0.1FP10, so I assume the problems are also in earlier versions. Problem 1 The server is hosting over 1000 NSF sharing the same design + some other custom apps. Not all NSFs are used via web as the app still has classic Notes UI in parallel, so it's a bit tricky to estimate the load. By using tell http xsp show modules I usually see around 350 NSFs active. We kept the default application timeout that should provide reasonable application recycling if it's not used continuously.  We started to...