computer reliability

system.http://google.com/search?q="Deepwater.Horizon"+DrillWorks+%2BDrillWorks+-inurl:groups+-JeffM&hl=all

platform

Yes the rate has declined, it is still too common.

Wow, you are seriously misinformed here. Funky cards for interface to strange, even one-off equipment, used to be normal in the BSD world. The PLC world experimented with M$ compatability and found it more trouble than they wanted. Worse the PLC world found that M$ front end tools became popular but drivers were always problematic. Now the old hats are gone and they are between a rock and a hard place. Consider the security implications of that.

The lawsuits are already there. Just not much mentioned.

Try, throw, catch exceptions is relatively new in programming.

But...

MSFT's latest MSIE-9 demo code source has an empty exception handler.

So, ignoring the available error handling language constructs is as bad as using the wrong language. Management possibly think they're doing the right thing, but the reality is that code works with empty exception handlers, as long as you don't test those exceptions :(

AFAIR the compiler doesn't report unhandled exception for an empty handler.

So it all looks good for the reports. Fails in reality?

Grant.

You wont get a year's uptime on WinXP if you *use* the system, and Win7 still needs regular rebooting to keep it happy. Larger memory and faster CPUs hide the issues for longer these days.

And, MSFT is planning to build safe rebooting into the next windows version. That is, one may hit the reset switch and the system will reboot *without losing user data*. So much for MSFT uptime.

Linux only needs a reboot to install a new kernel, and, there's an optional way around that too (see kexec).

Grant.

But that's the point, no? Lots of places take the same risks, yet they're only found out after disaster strikes. Risk management :(

I suppose BP and their contractors are still in front, if not, they'll call on the govts to fix things, like the failing banks did. We live in corrupt times.

Grant.

Only over 20 years old, i was using constructs of that nature by 1987. Plus, i think it was standardized in "C" in 1999. Plus "assert" goes all the way back to K&R days.

Wouldn't know, i don't expect to ever test MSIE-9.

Nested exception handling is nothing new, there was a complete chapter about it in the VAX/VMS Architecture Handbook from the mid 1970's.

I have never seen an OS, not even Windows crashed by an application programmer divide by zero. I have seen multiuser VAXes brought to their knees by naive undergraduate code transposing large arrays though. It was still running just very very slowly with everything I/O bound.

Most minimal embedded kernels would survive this and if you are lucky log it dump the registers and report the address where the exception occurred for later fixing. One of the most expensive bugs ever was the range checking exception handler on the Ariane 5 test launch 501:

The improved SRBs allowed it to go faster downrange and a 16 bit integer conversion overflowed. It was doing a core dump down the booster control telemetry channel that ultimately caused the explosion.

Dynamically scoped exception handling goes back a lot further than that. PL/I in the late 60's had it and as a result of the trouble it caused Ada went for statically scoped exception handling.

C++ probably took the throw and catch concept from Common Lisp which also predates it. We were working on a compiler for CL in 1984 whilst the standard was still in flux.

Statically scoped exception handling like in Ada was better and more robust if you care about being able to understand large codebases.

A history of exception handling and sample user exception handlers in various languages exists on Wiki, but the following comments are good:

MS are a conundrum. Some of their practitioners have written eminently sensible books on good industry practice like Steve McConnells code complete. But still they have loads of buffer overruns and code where debug asserts have other side effects. It is telling that code metrics (which look for roughly the equivalent in code of dry solder joints in hardware) are only in the most expensive industrial team versions of their software and not in the educational, professional or hobby ones.

If you don't teach people to use the best available tools from the outset they quickly acquire bad habits.

Regards, Martin Brown

C doesn't have try/catch; that's C++ (which first appeared in 1983 but wasn't ratified as a standard until 1998, and exceptions were one of the last features to be reliably implemented, which meant that programmers often avoided using them).

The only "exceptions" in C99 are floating-point exceptions, which either set a flag or generate a signal.

You can implement the equivalent of catch/throw in C using setjmp/longjmp, but you have to maintain your own handler stack, and there's no way to implement "finally".