Dear fellow CAP practitioners,
One of the Added features in nodejs version of cds@8.2.0 is the “New config flag `cds.server.shutdown_on_uncaught_errors` allows to control whether the server should shut down on uncaught errors. Default is `true`”. Is this a pointer to CAP (nodejs) moving away from “let it crash”?
I tried to see if I can keep the old behavior (missing in cds@8.1) and invoked an operation with undefined variable. This would crash the server in cds@7 and cds@6. But to my surprise, the server did not crash, with or without the new flag. It does crash if I switch to the old odata parser though (features.odata_new_adapter:false). So the new parser is already ready to chug along even with previous uncaught exceptions.
It appears the REST adapter never bought into “let it crash”. It was already doing what the new odata adapter does in cds@7. It responds with 500 and is ready for the next request.
There were many who doubted the “let it crash” approach in the community, Is the CAP Error Handling approach of “Let It Cras… . Is CAP listening these voices? What about the inherent concerns about unhandled errors leaving the single threaded server in a bad state.
What do you think? Is this a good way forward for CAP in nodejs?
regards,
Dinu
Dear fellow CAP practitioners,One of the Added features in nodejs version of cds@8.2.0 is the “New config flag `cds.server.shutdown_on_uncaught_errors` allows to control whether the server should shut down on uncaught errors. Default is `true`”. Is this a pointer to CAP (nodejs) moving away from “let it crash”? I tried to see if I can keep the old behavior (missing in cds@8.1) and invoked an operation with undefined variable. This would crash the server in cds@7 and cds@6. But to my surprise, the server did not crash, with or without the new flag. It does crash if I switch to the old odata parser though (features.odata_new_adapter:false). So the new parser is already ready to chug along even with previous uncaught exceptions. It appears the REST adapter never bought into “let it crash”. It was already doing what the new odata adapter does in cds@7. It responds with 500 and is ready for the next request. There were many who doubted the “let it crash” approach in the community, Is the CAP Error Handling approach of “Let It Cras… . Is CAP listening these voices? What about the inherent concerns about unhandled errors leaving the single threaded server in a bad state. What do you think? Is this a good way forward for CAP in nodejs? regards,Dinu Read More Technology Blogs by Members articles
#SAP
#SAPTechnologyblog
