"Walter Bright" <newshou...@digitalmars.com> wrote in message news:golmnp$2i2...@digitalmars.com... > Nick Sabalausky wrote: >> "Walter Bright" <newshou...@digitalmars.com> wrote in message >> news:gole1d$23v...@digitalmars.com... >>> Rainer Deyke wrote: >>>> Writing an assertion for every non-nullable reference argument for >>>> every >>>> function is tedious. >>> It's also quite unnecessary. The hardware will do it for you, and the >>> debugger will tell you where it is. >>> >> >> Yes...at run-time. > > Asserts only fire at run-time, too. This is why I said the asserts are > pointless. > >> And even then only if you're lucky enough to hit all of the code paths >> that lead to a null-reference during testing. It might not cause >> data-corruption, but it does cause a crash. > > It's not *remotely* as bad as data corruption. Back in the bad old DOS > days, a data corruption problem could, and often *did*, completely > scramble your hard disk. Having protection against this in hardware was an > enormous improvement. > > Things were so bad on DOS with this I'd develop code on a different system > entirely that had memory protection, then only afterwards port it to DOS > as a last step. > > >> A crash might not typically be as bad as data-corruption, but both are >> still unnaceptable in professional software. Plus, a crash *can* be >> nearly as bad, if not equally bad, as data-corruption when it occurs in >> something mission-critical. This is not a problem to be taken lightly. > > I've worked with mission-critical software. You absolutely do NOT rely on > it never failing. You design it so that when it fails, and it WILL fail, > it does not bring down your critical system. > > I started my career doing flight critical mechanical designs for Boeing > airliners. I had it pounded into me that no matter how perfect you > designed the parts, the next step is "assume it fails. Now what?" That is > why Boeing airliners have incredible safety records. > > Assume the parts break. Assume the hydraulics are connected backwards. > Assume all the fluid runs out of the hydraulics. Assume it is struck by > lightning. Assume it is encased in ice and frozen solid. Assume the cables > break. Assume a stray wrench jams the mechanism. Assume it rusts away. > Assume nobody lubricates it for years. Assume it was assembled with a bad > batch of bolts. Etc. > > If software is in your flight critical systems, the way one proceeds is to > *assume skynet takes it over* and will attempt to do everything possible > to crash the airplane.
You're dodging the point. Just because these failsafes might exist does *NOT* excuse the processes from being lax about their reliability in the first place. What would Boeing have said if you designed a bolt with a fatal flaw and excused it with "It's ok, we have failsafes!". A failsafe is good, but even with one, it's far better to not even have the failure in the first place. Like Denis pointed out with the Chrome example, there's only so much that a failsafe can actually do. So, ok, even if data-corruption is much worse than a null-reference crash, a null-reference crash is *still* a major issue.
