[tip] How to suppress the long scroll after a crash of cap server [node.js]
If you are like me, you make silly mistakes, typos mostly when writing custom logic for a service in CAP(nodejs) project. As annoying as this is, what is even more frustrating is that the message after the crash is so long that, where the error occurred and what the error is, is lost in scrolling to locate it. When in the terminal in Business Application Studio, this is even more painful.
You want to let it crash when there is such programming error, you don’t want to be wrapping everything you write in try-catch blocks to catch such errors. The framework is already reporting the error with stack trace. It is the dump of the enormously large request that is making it painful to find this useful message on the terminal. So what we need is to suppress dumping of this enormously large object obscuring what is helpful.
The dump is of the Promise that was processing the request . CAP stores context of request processing in Async Local Storage. The context includes the request along with large objects like the target entity, query and data. Lets suppress the dump of the Promise and we should be able to get back to doing useful stuff than scrolling.
Save the following in a file in the cap project.
// file: ./silent-promise.js const util = require('util'); const sym=util.inspect.custom; Promise.prototype[sym] = () => "Promise..";
Before starting the CAP server, set the environment variable NODE_OPTIONS to “-r ./silent-promise” so that this is loaded by node process when it starts.
That’s it. Now the silly mistakes won’t force you into frustrating scrolling of the terminal or logs.
in Business Application Studio or in a bash terminal you can set the environment variable with:
export NODE_OPTIONS="-r ./silent-promise"
You will have to do this every time you open a new terminal.
In PowerShell same can be achieved with:
With that world is a little more forgiving than before.
An alternate approach would be to suppress dumping the context or make its dump brief. But, I found it unnecessary. All what I needed was in the logs from the framework already.
I am curious. Would you use this tip?