J
JosephKK
#3 applications must not crash other applications.
-
Categories
-
Platforms
-
Content
#3 applications must not crash other applications.
J
JosephKK
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.
J
JosephKK
The lawsuits are already there. Just not much mentioned.
G
Grant
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.
G
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.
G
Grant
Related story in latest comp.risks says they turned off the alarm
system at night so workers could sleep and not have to wake up for
the frequent false alarms at 3:30
Grant.
Kind of a clue that some serious things were let to just slide. If i
managed a $100 million rig and there was some sloppy and safety
critical software like that, the programmer would be on the rig
troubleshooting it 24/7. And maybe his boss to boot.
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.
J
JosephKK
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.
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.
Wouldn't know, i don't expect to ever test MSIE-9.
P
Paul Keinanen
Nested exception handling is nothing new, there was a complete chapter
about it in the VAX/VMS Architecture Handbook from the mid 1970's.
M
Martin Brown
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:
http://en.wikipedia.org/wiki/Ariane_5#Notable_launches
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:
http://www.csci.csusb.edu/dick/cs320/sebesta/14.html
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
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:
http://en.wikipedia.org/wiki/Ariane_5#Notable_launches
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:
http://www.csci.csusb.edu/dick/cs320/sebesta/14.html
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
N
Nobody
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".
Similar threads
- Showcase: Item
