Re: CMutex /CEvent (multiple threads)

Tech-Archive recommends: Fix windows errors by optimizing your registry

See below...
On Tue, 29 Sep 2009 05:23:52 -0700 (PDT), Goran <goran.pusic@xxxxxxxxx> wrote:

On Sep 28, 5:14 pm, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:
The problem with C++ is the assumption that "everything throws" is not clear, and it is
even less clear with some of the library functions in the MFC library, so ususally the
only check you ever get is when you get an unhandled exception.  This would not be so bad,
except that the MFC message dispatcher by default catches all CException-derived
exceptions, and just pops up a messagebox saying that there was an error.  This means that
an erroneous program keeps on running, whether it is now intact or not.

Well.. What's "erroneous"? Getting an exception certainly does not
equal having a bug.
****
Failing to handle an exception in a way that preserves correctness is an erroneous
program. The art of exception handling is to be able, at any point, to guarantee a
consistent state has been achieved. The actions after that can be
* Continue running
* Re-throw the exception
* Throw a new kind of exception
* Return a value indicating a problem
among others. If I fail to take an action, and the consequences of that action are a
failure, either catastrophic (access fault, typically due to failure to test a null
pointer; data structures are corrupted; incorrect or inconsistent data is left in
otherwise-correct data structures, among others) or transient (a transaction is lost,
which requires the poster of the transaction to retry it), then my program is erroneous.
****
There was a problem exception was raised, and that
was reported to the user. If exception __is__ caused by a bug, well,
that's a bug prior to exception. If not, problem is only when error
message is inappropriate ("Encountered an improper argument" that
happened who knows how deep means nothing once it bubbles out to
global wndproc.) But ProcessWndProcException is virtual, and, it is
still possible to catch in strategic places and turn into something
more meaningful (even if only better text). That offsets it pretty
well IMO.

I try to avoid the cleanup code in C by refactoring the code so there is an inner function
that returns true/false non-NULL/NULL, etc. and the "finally" code is always implemented
outside this by the caller, so my take is to always write

void Something()
   {
    ...set up state
    if(!InnerSomething())
       rollback
   else
      commit
  }

so the InnerSomething (here a BOOL type) simply does "return FALSE" any time a rollback is
required.  I've been doing this for years (I spent about 14 years programming in a
language which had no 'goto' at all in the language, so got used to this kind of
refactoring).

That's not bad, but it means splitting __every__ function that e.g.
handles some resources (or state) locally, into init/work/cleanup
phases. Consequences:

1. one gets a lot of trivial wrappers
2. if some resources/state are such that can be obtained later in the
works, one will get even more wrappers (there will be more
"innerSomethings")
3. eventual transfer of resource ownership gets harder due to more
functions involved.

But luckily, when working with C++, all this resource handling becomes
almost trivial, the tools offered by the language (RAII, non-throwing
swap) and "community" (e.g. ScopeGuard) are __that__ strong (to my
knowledge, there's nothing better).
****
Generally, the wrappers are not "trivial". They spend some work doing setup, and possibly
significant work doing rollback. So I don't consider these "trivial" actions.

I generally transfer resource ownership in structures, if the resources are more than a
single handle or pointer.

ScopeGuard is something new. I wonder if this a reinvention of a technique we did back in
1967, where we had a built-in rollback of global scope on exceptions? (A technique
invented by Jim Mitchell, who invented our exception handler, and myself, who needed a way
to roll back values whose extent exceeded the scope of the function).

Do you have a pointer to it?
joe
****

Goran.
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: CMutex /CEvent (multiple threads)
    ... even less clear with some of the library functions in the MFC library, ... only check you ever get is when you get an unhandled exception. ...     ...set up state ... But luckily, when working with C++, all this resource handling becomes ...
    (microsoft.public.vc.mfc)
  • Re: What c.l.pys opinions about Soft Exception?
    ...     return len ... handle a Soft Exception, it exists there if you need to handle the ... obfuscate the code since we have to separate distance calculation from ... it terminates the distance calculation ...
    (comp.lang.python)
  • Re: CMutex /CEvent (multiple threads)
    ... anything else provokes an exception. ...     protected: ... and we throw a CSyncTimeout exception on timeout!) ... and in the Lock() code it would look something like ...
    (microsoft.public.vc.mfc)
  • Re: Avoiding Default Parameter Checking in C# 4.0
    ... Occasionally an exception needs thrown in the middle of the private ...    void MethodA ... null and that it is not IList, why pay for the runtime overhead? ... calling a class's public methods from within the class. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Granularity of OSError
    ... LBYL would look like this: ...     os.unlink ... EAFP would look like this: ... the exception is indeed of the specific kind we're trying to catch. ...
    (comp.lang.python)