I have actually seen code like this in production. A "senior engineer" I worked with decided that C++ DOM parsing code was too verbose with so many checks for null child nodes, so he wrote a set of macros which wrapped setjmp/longjmp and trapped SIGSEGV to allow resuming any code that tried to traverse a null pointer.
If of course made debugging effectively impossible, not to mention catching all segfaults, not just those triggered by a DOM parsing error.
Ruby/Rails segfaults often enough for this to be (even jokingly) useful?
[Edit] Why downvote a genuine question instead of informing me why you think it's inappropriate? I would never have expected someone to write a fatal-signal-ignoring-handler for a scripting language, even as a joke, so I was curious as to whether Ruby/Rails processes did semi-regularly crash.
According to POSIX, after a SIGSEGV, the state of the program is undefined. This is the reason that a SIGSEGV usually causes an immediate abort. Allowing a program to execute when its state is undefined is a huge security hole.
"This is exactly what is wrong with the Ruby community. Rails has an option called "disable whiny nils"."
whiny_nils is an option to provide additional information with an error, not an option to disable errors. It's not remotely related to this and you clearly have no idea what you are talking about.
I can tell the author is aware of the risks, but I'm sure there are ruby users out there that think this is a good idea. This is exactly what is wrong with the Ruby community.
I'm literally rolling my eyes at this. You're actually "begging the question" — in the correct sense of the term!
Besides, going off on a tangent and randomly bashing the Ruby community stopped being cool like six months ago.
The problem is that I assume there are ruby users out there who think this is a good idea, even though I support that claim with the evidence of "disable whiny nils" in Rails?
I'm not "randomly" bashing the ruby community. This is a clever hack, but an extremely bad idea to use in production, and it comes fully packaged as a ruby gem that is ready to be deployed with "gem install".
The problem is that I assume there are ruby users out there who think this is a good idea, even though I support that claim with the evidence of "disable whiny nils" in Rails?
The problem's actually more subtle than that. The implication of what you said is that this is a problem with the Ruby community more so than some other communities. You provided no evidence for that claim at all. The disable whiny nils thing, by the way, doesn't do what you think it does.
I'm not "randomly" bashing the ruby community.
Sure you are. You're taking one library that happened to be written in Ruby and using it as an excuse to generally bash Rubyists.
This is a clever hack, but an extremely bad idea to use in production, and it comes fully packaged as a ruby gem that is ready to be deployed with "gem install".
This library is literally a joke. Although maybe not. I think Aaron is also a big fan of using Enterprise Ruby in production, which is why he released this: http://github.com/tenderlove/enterprise/tree/master
If of course made debugging effectively impossible, not to mention catching all segfaults, not just those triggered by a DOM parsing error.