>> Okay now how many people do check on the return value for fclose()

> I believe I've mention in one of the other "exceptions" threads that I was anal.  This is what I mean.  I will admit, I don't check it every Go ahead. Laugh!

Absolutly not, Most times I either forget about it, or are to lazy, or don't know what it should do else.


Well small stack traces are nice to have either way. For costumer support, if somebody calls you with the messge "your application just segfaulted", no matter what else he babbles, having a stack trace gives you a very defined idea where to problem arised. Especially on GUI application it's a nasty event if the application just vanishes from the user, at least a message box and some explanation what happened should appear. Okay windows learned this and now even KDE has nice crash handles, and if you've a debug build of KDE it does print out a nice stack trace, you can copy/paste for bug reports. But okay I think it's task of the application to handle segfault signals, and to investigate it's own status on this signal.

> Not everyone is building a Sherman tank.  (Or a Nuke Plant for that matter.)  There must be room for tradeoffs.

Yes I said it's overstated. On PC's it are more trivial things like FileIoException - write access not allowed. Something you can miss when coding an application, not thinking about your application could be runned in places where you don't have write access to your direction. Or the target system is malfunctioning because the current user doesn't even have access to /tmp, or somebody deleted the /tmp or whatever.

> PS:  I still like the idea of a nuclear meltdown being handled by a mere exception.  I can't imagine what it would be like to write the code that monitor the situation and just determine "hmm... The core is melting.  I guess I'll throw an exception.  My work is done."  :-)

Okay, okay it was a bad example, as normally there is even an own circuit respsonsible just for this. But staying in practical/physical world you've quite often conditions an producure says: man, under this situation I can never continue my task, and it -must- be handled proparly by a single instance. Just imagine every possible code loop would have to handle itself criticial errors, diffrerent programmers result in different solutions. So the answer to how does this system react on this or this situation? would have to be answered, well that depends on which state the software currently is.

Hmmm okay from my phantasy I've imagine a new hopefully better example. Take the airplane autopilot, in case of an engine starting to catch fire, the autopilot will no longer care to reach the target city or to fly in for maximum comfortability for the passanger. It raises an 'EngineCatchedFireException' :o) and code pops back until a main loop, which catches it, and handles the exception by giving control to a complete other code part, since flying with just one wing is very different than with two :o)  (but from what I heared it's still possible). Again if the application exits with a callback stack.... okay enough phantasy :o)

- Axel

> I've gone on longer about this than I ever intended to.

Sorry if I was importunate/stolid :/

- Axel

Dan Hursh wrote:

> You can get idiots in any language.

"If you invent an idiot-proof computer...they will invent a better idiot!"

> If you find a language feature
> that could fix that, I would truly be impressed.  I'll assume you meant
> to say "...if you call a library function that DOESN'T declare its
> exceptions..", or else you are misrepresenting my argument.  First, this
> hypothetical API designer is an idiot and the API should be considered
> flawed.  Some programs can afford to be quick and dirty.  No public API
> should.

Absolutely.  I didn't mean to imply that having non-strict throws clauses would *cause* bad library APIs.  What I was intending to say was that programmers are fundamentally lazy, and that the use of the language will tend to gravitate towards the quickest & dirtiest way.  If the default setting of the language is to have strict exceptions, I would guess that more programs (and a higher percentage of library APIs) will use it so as to "not have to bother with the compiler switches." Ofc, you will always have idiots and anal people on both ends in any language.

Having this be the default puts additional pressure on designers of library APIs to write "good" APIs.  If they want their API to be interoperable with my program, and the default of my compiler is to require strict exceptions, they are more likely to declare those strict exceptions "just to make it work."

Axel Kittenberger wrote:
> > PS:  I still like the idea of a nuclear meltdown being handled by a mere exception.  I can't imagine what it would be like to write the code that monitor the situation and just determine "hmm... The core is melting.  I guess I'll throw an exception.  My work is done."  :-)
> 
> Okay, okay it was a bad example, as normally there is even an own circuit respsonsible just for this. But staying in practical/physical world you've quite often conditions an producure says: man, under this situation I can never continue my task, and it -must- be handled proparly by a single instance. Just imagine every possible code loop would have to handle itself criticial errors, diffrerent programmers result in different solutions. So the answer to how does this system react on this or this situation? would have to be answered, well that depends on which state the software currently is.
> 
> Hmmm okay from my phantasy I've imagine a new hopefully better example. Take the airplane autopilot, in case of an engine starting to catch fire, the autopilot will no longer care to reach the target city or to fly in for maximum comfortability for the passanger. It raises an 'EngineCatchedFireException' :o) and code pops back until a main loop, which catches it, and handles the exception by giving control to a complete other code part, since flying with just one wing is very different than with two :o)  (but from what I heared it's still possible). Again if the application exits with a callback stack.... okay enough phantasy :o)

Sorry.  For some reason the whole scenario about the nuke plant came to me as a twisted Monty Python skit.  It was a valid example of a critical application, exaggerated but that just helps to punctuate the idea.  I just got this weird idea about it into my head and it gave me a good chuckle.  I'm just warped.

Dan

Long time ago I wrote code that tried to go around error handlings by 'recovery' and all kinds of code to somehow halt along after problems. Usually such code ended up becoming far too complex, resulting in even more unknown states. The best is to let the application bomb as quickly as possible, and force the programmer to fix the problem on the spot. Hence delegating the error handling to another level and even ignoring is in my current view not a practical solution. In embedded systems programming it's far better to have the program crash and then you are indeed forced to fix the problem before shipping it. --Kent

Kent Sandvik wrote in message <9n8n4u$ai5$1@digitaldaemon.com>...
>Long time ago I wrote code that tried to go around error handlings by 'recovery' and all kinds of code to somehow halt along after problems. Usually such code ended up becoming far too complex, resulting in even more unknown states. The best is to let the application bomb as quickly as possible, and force the programmer to fix the problem on the spot. Hence delegating the error handling to another level and even ignoring is in my current view not a practical solution. In embedded systems programming it's far better to have the program crash and then you are indeed forced to fix the problem before shipping it. --Kent


I've had a long standing disagreement with some people who think that programs should attempt to recover from their own bugs. My feeling is that if a fault is detected, fail immediatedly. Trying to recover from them is like duct taping over rust.