> Recovery is only as good as the language framework allows it to be. > Compilers insulate you from the data and the hardware, and > reduce your level > of control over how errors are handled. > But that's part of what you're buying by using a compiler in the first > place: Not to have to worry about all those "little details".
I don't disagree that having the compiler worry about some things is OK; it's more the assumption that "oh, this is Java so I don't have to do return code checking or worry about that 10G malloc() call on a small machine" that gets me miffed. No matter what language you use, there's still some basic sanity checking that has to be done to ensure stability, and it's getting rarer and rarer. > An infinitely smart programmer > could conceivably > write enough code to fix or recover from ANY failure, but how > many of THOSE > are there? Nobody's asking for perfection, but stupid little stuff like not checking arguments for sanity or indexing off the end of a string because you're too lazy to check the length before you increment is just lousy style. Eradicating code like that is a moral imperative. > And who writes in assembler anymore anyway? Still a fair amount of it for those of us doing embedded work. :caveman. Me Make Hardware Go. Ugh. :ecaveman. -- db
