George
Tue Jan 08 08:08:01 CST 2008
Thanks Igor,
Great!
About your below comments, I agree and I have checked again the the code is
the same as Bjarne's code in the book -- I have not made any typo. :-)
BTW: how do you think we should correct the code? Could you provide some
correct code please?
> I wonder if this is going to work. An exception is a temporary object.
> You are saving an address of a temporary, but I strongly suspect
> Network_exception object will be destroyed as soon as throwY exits (by
> throwing another exception), at which point your Yunexpected instance
> will hold a dangling pointer. Unless of course Yunexpected's constructor
> allocates a copy of its parameter on the heap and saves a pointer to
> that copy, or otherwise extracts and saves off some information from its
> parameter before it's destroyed.
regards,
George
"Igor Tandetnik" wrote:
> "George" <George@discussions.microsoft.com> wrote in message
> news:7B351A53-4DBC-43ED-874C-C073E038B899@microsoft.com
> > This question is about when it is allowed to call throw to re-throw
> > exception -- make the exception re-throw.
> >
> > I can only think of two situations,
> >
> > 1. in catch block of an exception;
> > 2. in unexpected handler.
>
> Any function can contain a "throw;" statement. Such a function can be
> called from a catch clause (or from unexpected() handler), directly or
> indirectly:
>
> void rethrow() { throw; }
>
> try {...}
> catch (const exception&) { rethrow(); }
>
> If "throw;" statement is encountered while no exception is caught, the
> program calls terminate().
>
> > For (2), in unexpected handler, since the input parameter is null, so
> > in order to get the exception information, we need to re-throw it and
> > catch it to get exception informaiton.
> >
> > Is my understanding correct?
>
> Sounds about right.
>
> > Here is some pseudo code from Bjarne's
> > book.
> >
> > [Code]
> > // suppose throwY is unexpcted handler
> > void throwY() throw (Yunexpected)
> > {
> > try{
> > throw; // have to re-throw and catch in order to get exception
> > information since current input parameter is null and has no exception
> > information, my understanding correct?
> > } catch (Network_exception& p)
> > {
> > throw (Yunexpected (&p));
>
> I wonder if this is going to work. An exception is a temporary object.
> You are saving an address of a temporary, but I strongly suspect
> Network_exception object will be destroyed as soon as throwY exits (by
> throwing another exception), at which point your Yunexpected instance
> will hold a dangling pointer. Unless of course Yunexpected's constructor
> allocates a copy of its parameter on the heap and saves a pointer to
> that copy, or otherwise extracts and saves off some information from its
> parameter before it's destroyed.
>
> > } catch (...)
> > {
> > throw (Yunexpected (0));
> > }
> > }
> > [/Code]
>
> Note that you've entered unexpected() handler in the first place because
> some function has thrown an exception that wasn't on its exception
> specification list. Your handler throws another exception, Yunexpected.
> At this point, one of three things can happen:
> a) the function's exception specification lists Yunexpected. In this
> case, execution continues as if the function had thrown Yunexpected from
> the beginning.
> b) the function's exception specification doesn't list Yunexpected, but
> does list std::bad_exception. In this case, execution continues as if
> the function had thrown bad_exception
> c) Neither Yunexpected nor bad_exception are listed in the function's
> exception specification. In this case, the program calls terminate().
>
> This means that, since the point of throwY handler seems to be to
> convert all unexpected exceptions to Yunexpected wrapper, every function
> in your program that has exception specification at all should mention
> Yunexpected in it. Otherwise your handler is pointless.
>
>
> Finally, it should be noted that many (most?) C++ experts believe that
> exception specifications, as specified in the C++ standard, are a
> mistake and should not be used. See for example
>
>
http://www.gotw.ca/publications/mill22.htm
>
> --
> With best wishes,
> Igor Tandetnik
>
> With sufficient thrust, pigs fly just fine. However, this is not
> necessarily a good idea. It is hard to be sure where they are going to
> land, and it could be dangerous sitting under them as they fly
> overhead. -- RFC 1925
>
>
>