Prev: Deleting all panes when Miniframe is Closing
Next: How to get crash dump when a unhandled CException is thrown by a MFC app
From: Giovanni Dicanio on 11 Jan 2010 03:17
"Joseph M. Newcomer" <newcomer(a)flounder.com> ha scritto nel messaggio
news:tvpkk5lqapu8c43ncog8sf48v64369rsa3(a)4ax.com...

> Just looking at stdexcept, it doesn;t even mention bad_alloc as an
> exception; it mentions

I think std::bad_alloc is defined in <new> .


> Building software that runs 24/7 means that NO error condition is allowed
> to be considered
> "fatal", every failure, for WHATEVER cause (bad input, program bug, who
> cares?) must
> result in a clean continuation of execution. I've built systems that
> recover from
> allocation failure, stack overflow, data overruns, etc., and it takes a
> LOT of work to
> make these do clean recovery. We had one where we did storage compaction!
> Try THAT in
> your standard C environment! [No, it is NOT fun! It required very
> careful programming,
> and essentially, all important structures were reachable from a small
> number of known
> roots, and no pointers to ANYTHING were ever retained except in the
> structures themselves.
> Our environment made it possible to discover, in these structures, where
> the pointers
> were. We probably poured 10 programmer-years into this recovery, but the
> program NEVER
> failed! Back in those days, of machines with 256K, running out of memory
> was a
> commonplace problem, and we built an entire virtual VM resembling Windows
> 1.0 to deal with
> this, ca. 1972. And the language wasn't C, but was functionally
> equivalent to it in all
> ways]
>
> By the way, building that system in 1972 led to some of the work in
> exceptions that
> appeared in our later compilers. Trying to build robust software without
> an exception
> mechanism is a losing game.

Walking down the memory lane, I recall that with my Commodore Amiga 500
there were the so called "Guru Meditations":

http://upload.wikimedia.org/wikipedia/commons/d/db/Guru_meditation.gif

http://en.wikipedia.org/wiki/Guru_Meditation

I don't know if the Amiga OS developers used C or assembly to write the OS,
but that was certainly an example of "just crashing" when an error occurred.

Giovanni


From: Goran on 11 Jan 2010 03:17
On Jan 11, 1:12 am, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> I do not believe it could possibly be a "genuine bug".  An exception thrown by the
> standard library indicates an error.  But the source of the error does not necessarily
> imply a "bug".

Yes, my post was a total brainfart (see my response to Giovanni), I
apologize for that. I rather wanted to say that any standard exception
without a good catch (whatever that might mean, but e.g. in a message
handler code) should be treated as a bug. That goes along with my
other stance that in MFC code, one should only have only MFC
exceptions flowing "freely".

Goran.
From: Goran on 11 Jan 2010 03:30
On Jan 8, 10:15 pm, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> See below...
>
>
>
> On Fri, 8 Jan 2010 12:09:05 -0800 (PST), Goran <goran.pu...(a)gmail.com> wrote:
> >On Jan 8, 4:37 pm, Peter Schneider <peter.m.schnei...(a)gmx.de> wrote:
> >> On 7 Jan., 15:32, Goran <goran.pu...(a)gmail.com> wrote:
>
> >> > In particular, though, I do think that CInvalidArgException is bad,
> >> > because it's usually a sign of a bug in the program. But exceptions
> >> > are strictly __NOT__ a mean to treat bugs, not in the slightest. On
> >> > top of that, there's this unlucky change in behavior between MFC
> >> > versions (bad index would essentially crash before, but will throw
> >> > now).
>
> >> If I remember correctly, Java uses exceptions for both "normal" error
> >> handling and for reporting programming errors including assertions.
> >> And that seemed to work pretty well and has the advantage that there
> >> is only one mechanism used.
>
> >> Contrast this to C++ and in particular to C++ on WIN32 where there are
> >> many different handlers for all kinds of unexpected errors (e.g.
> >> _set_abort_behavior, _set_purecall_handler,
> >> set_terminate,set_unexpected, SetUnhandledExceptionFilter, ...)
>
> >> So where do you see the general problem with using exceptions to
> >> report programming errors?
> >> And how do you think programming errors should be reported in C++?
>
> >Clear-cut theoretical answer, for me, is: code that errs should crash,
> >preferably with a crash dump and as soon as possible. That's
> >invaluable for the ease of development, because that helps the most in
> >finding the source of the problem.
>
> >Of course, in practice, things get muddy. Often, once error is
> >detected, it's already too late (e.g. stranded pointer). OTOH, with
> >that drastic approach, "user experience" suffers. I'd guess that
> >numerous coders have been forced by their respective marketing or
> >whatever departments to try to continue running even though there's
> >something horribly wrong, and frankly, I can see that point, too.
>
> ****
> One thing I learned many, many years ago (1976, to be exact): It doesn't matter if it is
> right if it fails-soft and recovers cleanly.  Seriously.  If the goal is to run without
> failure, there are two critical approaches
> (1) make sure there are no failures
> (2) make sure all failures recover in a way that does not impair functionality or
> correctness
>
> I spent months trying to achieve (1), only to conclude that we had an intermittent
> hardware problem.  So I went to (2), and even when the hardware failed, I was able to
> recover cleanly.  I took the MTBF from 45 minutes to 6 weeks (at which point, everything
> was going well, but building power failed when a crane toppled across both the primary
> input feed and the backup input feed, which were three feet apart!)  We had a hardware
> failure at least once a day, which caused an exception to be thrown, and we recovered.
>
> We always harbored the thought that there really was a bug that set a NULL pointer, as
> opposed to a memory glitch that returned 0, but after a while it no longer mattered.  We
> could never find the bug, if it existed.  But the system never stopped.
>
> It did take me a year to make this completely bulletproof.  
>
> So I do not believe that throwing an exception should terminate a program; rather, I think
> throwing exceptions is a well-structured way to create programs that don't fail.
>
> Sometimes, the recovery involved re-certifying the integrity of individual data
> structures, and that certification itself could potentially throw exceptions (we had no
> way to ask "is this a valid address?" without trying to read it and taking an exception).
> I do not think it makes sense to think that terminating a program immediately if an
> exception is thrown is the one-and-only possibility.  In the real world, I want options to
> save state, close files, clean up relevant system state, and if possible, continue correct
> operation.

In all honesty, you can't put up front the claim that any given code
one should defend itself against a hardware error like that. If some
stock PC has that, it's not a duty of my MFC code to defend from that.
Instead, the owner of a PC should have it working correctly first.
Heck, if you had your code deployed on a machine with a virus on, and
you got a complaint that it's not running well, what would you say to
that? "Go and fix your machine", that's what.

OTOH, I, for example, interface with embedded systems. On more than
one occasion, I had to fix problems on the embedded side. And quite
recently, a hardware problem on the embedded side. But it was a
question of what is the best approach to solve the problem, and in
this case, hardware was already deployed.

So the crux of what I am saying, I guess, is: it's a question of who
is deemed responsible to fix the problem, fair on unfair, for better
or for worse. So if in your 1976 case, you couldn't have your faulty
hardware replaced, could you? And so problem was fixed by other means.

Goran.
From: Peter Schneider on 11 Jan 2010 04:05
On 8 Jan., 21:09, Goran <goran.pu...(a)gmail.com> wrote:
> Clear-cut theoretical answer, for me, is: code that errs should crash,
> preferably with a crash dump and as soon as possible. That's
> invaluable for the ease of development, because that helps the most in
> finding the source of the problem.
>
> Of course, in practice, things get muddy. Often, once error is
> detected, it's already too late (e.g. stranded pointer). OTOH, with
> that drastic approach, "user experience" suffers. I'd guess that
> numerous coders have been forced by their respective marketing or
> whatever departments to try to continue running even though there's
> something horribly wrong, and frankly, I can see that point, too.

I fully agree with your theoretical answer and also with the fact that
in practice there can often will be other requirements. But the latter
depends a lot on the respective application (and maybe also company
policy).

> I personally would not touch most of functions you list there -
> problems that cause them to be invoked are way too bad for me to try
> to get smart. So quick death there, using the default behavior.
> (Luckily, I don't remember when was the last time I got pure e.g.
> virtual call error). I do use SetUnhandledExceptionFilter to produce
> crash dump, though (but I TerminateProcess immediately after that).

I completely agree. I'd also prefer to get a crash dump and terminate
in those cases. But as a side note: I had some problems with the
default behaviour of some of those handlers recently. The dump files
that were written looked sort of random under certain circumstances. I
posted about this to another news group and the issue is basically
still open. In case you are interested, the link is:http://
groups.google.com/group/microsoft.public.windbg/browse_frm/thread/
37e2f13f7ad05e6d#. It's

> WRT Java situation - I am ambivalent WRT benefits in mixing exceptions
> caused by bugs and "legitimate" exceptions (ones caused not but bugs
> but rather by "unusual" conditions). I think that such environments
> continue even in case of an error-exception is more consequence of
> general programming model  where all throws, than a conscious decision
> to do so.
>
> Goran.- Zitierten Text ausblenden -
>
> - Zitierten Text anzeigen -

From: Peter Schneider on 11 Jan 2010 04:26
On 8 Jan., 22:15, Joseph M. Newcomer <newco...(a)flounder.com> wrote:
> Sometimes, the recovery involved re-certifying the integrity of individual data
> structures, and that certification itself could potentially throw exceptions (we had no
> way to ask "is this a valid address?" without trying to read it and taking an exception).
> I do not think it makes sense to think that terminating a program immediately if an
> exception is thrown is the one-and-only possibility.  In the real world, I want options to
> save state, close files, clean up relevant system state, and if possible, continue correct
> operation.
>
> Have you noticed sometimes when Office crashes, it saves the current file in its
> best-possible recent state?  Not an accident.  Adobe's FrameMaker works the same way.

I don't think anyone suggested that an application should always be
terminated immediately when an unhandled exception or internal error
of any kind occurs. I definitely agree that we need to have options
such as you suggested.

In my opinion it is much easier to fix programming errors when the app
really crashes (particularly these days when they are reported via
windows error reporting), ideally after minimizing the damage (e.g.
saving the user's input).

With MFCs catch() I don't seem to have that option ...



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Deleting all panes when Miniframe is Closing
Next: How to get crash dump when a unhandled CException is thrown by a MFC app