Re:Node.js running in the new Airbus A350 inflight servers
by verelo on Saturday November 28, 2015 @04:11PM
(#10642449)
Sorry its really not intended to be a personal attack and i regret the wording.
To clarify what I was trying to convey, the issue I personally find is that JS errors often produce difficult to understand descriptions and misleading traces when compared to some alternative languages.
I do believe that there is good work being done to convert these errors into more usable alternatives. Just recently I caught a glimpse of this: https://plus.google.com/+AddyOsmani/posts/DdWkiKsvbA2
Segmentation faults can also be very cryptic, especially in the memory related cases like you suggested, but its likely that any tool would behave in fairly unpredictable ways when it comes to any form of corruption or out of memory scenario.
Sorry again and hopefully that clarifies my thoughts.
I'm not sure I understand this. Can't you get a backtrace out of a JavaScript exception just as well as you can get one out of a segfault? The segfault itself doesn't carry any information other than at best the faulting instruction and the nature of the fault, and you can surely get that out of a JavaScript exception.
Furthermore, a segfault is very often a sign of memory corruption that has already happened, possibly in the stack frames themselves. "undefined is not a function" is not. JS code that crashes with that error is in a much more debuggable state than native code that crashes with a segfault. And you can certainly configure your interpreter to take a coredump on an uncaught JS exception, which will definitely be more debuggable than a coredump post-memory corruption.
(Your personal attack is not an argument.)