On May 30, 2012, at 5:58 PM, "Kapps" <opantm2+s...@gmail.com> wrote:
> On Wednesday, 30 May 2012 at 22:22:01 UTC, Jonathan M Davis wrote: >> On Thursday, May 31, 2012 00:01:16 deadalnix wrote: >>> Most segfault are null deference or unintizialized pointer deference. >>> Both are recoverable. >> >> If you dereferenced a null pointer, it's a bug in your code. Your code is >> assuming that the pointer was non-null, which was obviously incorrect, >> because >> it was null. That's _not_ recoverable in the general case. Your code was >> obviously written with the assumption that the pointer was non-null, so your >> code is wrong, and so continuing to execute it makes no sense, because it's >> in >> an invalid state and could do who-knows-what. If there's any possibility of a >> pointer being null, the correct thing to do is to check it before >> dereferencing it. If you don't, it's bug. >> >> Now, it's perfectly possible to design code which never checks for null >> pointers and if a null pointer is dereferenced throws an Exception and >> attempts to recover from it (assuming that it's possible to detect the >> dereference and throw at that point, which AFAIK is impossible with segfaults >> - maybe it could be done on Windows with its Access Violations, but segfaults >> trigger a signal handler, and you're screwed at that point). But writing code >> which just assumes that pointers are non-null and will throw if they are null >> is incredibly sloppy. It means that you're treating pointers like you'd treat >> user input rather than as part of your code. >> >> - Jonathan M Davis > > All code has bugs in it. It's nice being notified about it and all, but if > you release a server application, and it crashes every single time it > encounters any bug... well, your customers will not have a fun time. It's worth noting that Google apps abort on error. For server apps, a process crash is often designed to be invisible to the client, as much to allow seamless code upgrades as anything.