In article <1994Dec13.200927.13489@fx.com>, Dan Moen <dmoen@fx.com> wrote:
>On reading Plauger's new book "The Draft Standard C++ Library," as well
>as various other sources, including the ARM and "The C++ Programming
>Language (2nd Ed.)," it appears that there are two proposals for
>exception throwing styles:
>
>(1) one line style:
> if (bad_stuff) {
>  throw exception("descriptive text goes here");
> }
>
>(2) virtual raise method style:
> if (bad_stuff) {
>  exception ex("descriptive text goes here");
>  ex.raise();
> }
>
>    where raise() is a virtual method in the exception class heirarchy
>    that (usually) invokes "throw *this;"
>
>Option (1) is more terse, and in some ways more clear, while option (2)
>allows a bit more control over the circumstances where exceptions are to
>be generated, including the ability to turn them off altogether.
>
>Thoughts and comments from the standards community are appreciated, either
>by post or e-mail.

One advantages option 2 has is that if you get in the habit, you are
less likely to write

        void f(..., Exception &e, ...)
        {
          ...
          if (bad_stuff) {
             throw e;
          }
          ...
        }

instead of

        void f(..., Exception &e, ...)
        {
          ...
          if (bad_stuff) {
             e.raise();
          }
          ...
        }

The first style throws based on the static type of the expression
being thrown, and will look for a handler of type Exception (or one of
its parents), whereas the second (since raise is virtual) will throw
based on the manifest type of the exception and can be caught by an
appropriate more-specific handler.

In the example given, the manifest and static types are the same, but
my preferred coding style is still 2.

In either case, the fact that the manifest and declared types may
differ argues for always declaring a virtual raise() function if your
exceptions form a heirarchy.

I actually toyed with the idea of suggesting a "virtual operator
throw()" to declare that I wanted exceptions derived from this class
to be thrown based on manifest type.

Evan Kirshenbaum         +------------------------------------
    HP Laboratories         | Giving money and power to government
    3500 Deer Creek Road, Building 26U | is like giving whiskey and car keys
    Palo Alto, CA  94304        | to teenage boys.
           |                   P.J. O'Rourke
    kirshenbaum@hpl.hp.com        |
    (415)857-7572

dmoen@fx.com (Dan Moen) writes:

>(1) one line style:
> if (bad_stuff) {
>  throw exception("descriptive text goes here");
> }
>
>(2) virtual raise method style:
> if (bad_stuff) {
>  exception ex("descriptive text goes here");
>  ex.raise();
> }
>
>    where raise() is a virtual method in the exception class heirarchy
>    that (usually) invokes "throw *this;"

I'd just like to point out that you can also write (2) more tersely:

 if (bad_stuff) {
  exception("descriptive text goes here").raise();
 }

>Option (1) is more terse, and in some ways more clear, while option (2)
>allows a bit more control over the circumstances where exceptions are to
>be generated, including the ability to turn them off altogether.

Last I heard, the committee had decided to drop the extra machinery
required for (2) and go with (1).

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <1994Dec13.200927.13489@fx.com>, Dan Moen <dmoen@fx.com> wrote:
>On reading Plauger's new book "The Draft Standard C++ Library," as well
>as various other sources, including the ARM and "The C++ Programming
>Language (2nd Ed.)," it appears that there are two proposals for
>exception throwing styles:
>
>(1) one line style:
> if (bad_stuff) {
>  throw exception("descriptive text goes here");
> }
>
>(2) virtual raise method style:
> if (bad_stuff) {
>  exception ex("descriptive text goes here");
>  ex.raise();
> }
>
>    where raise() is a virtual method in the exception class heirarchy
>    that (usually) invokes "throw *this;"
>
>Option (1) is more terse, and in some ways more clear, while option (2)
>allows a bit more control over the circumstances where exceptions are to
>be generated, including the ability to turn them off altogether.
>

Maybe I'm wrong. but given (1) can't you do (2)?

In article <9434822.6096@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>dmoen@fx.com (Dan Moen) writes:
>
>>(1) one line style:
>> if (bad_stuff) {
>>  throw exception("descriptive text goes here");
>> }
>>
>>(2) virtual raise method style:
>> if (bad_stuff) {
>>  exception ex("descriptive text goes here");
>>  ex.raise();
>> }
>>
>>    where raise() is a virtual method in the exception class heirarchy
>>    that (usually) invokes "throw *this;"
>
>I'd just like to point out that you can also write (2) more tersely:
>
> if (bad_stuff) {
>  exception("descriptive text goes here").raise();
> }

If all raise() does is "throw *this" then you can write it even more
tersely than that:

    if (bad_stuff) {
 throw exception("descriptive text goes here");
    }

If you're holding the exception by value, invoking raise() on it will
not utilize the virtual function invocation mechanism, so you might as
well just throw it by value and forget the raise() function.

--steve

Steve Vinoski  vinoski@ch.hp.com        (508)436-5904
Distributed Object Computing Program    fax: (508)436-5122
Hewlett-Packard, Chelmsford, MA 01824

On reading Plauger's new book "The Draft Standard C++ Library," as well
as various other sources, including the ARM and "The C++ Programming
Language (2nd Ed.)," it appears that there are two proposals for
exception throwing styles:

(1) one line style:
 if (bad_stuff) {
  throw exception("descriptive text goes here");
 }

(2) virtual raise method style:
 if (bad_stuff) {
  exception ex("descriptive text goes here");
  ex.raise();
 }

    where raise() is a virtual method in the exception class heirarchy
    that (usually) invokes "throw *this;"

Option (1) is more terse, and in some ways more clear, while option (2)
allows a bit more control over the circumstances where exceptions are to
be generated, including the ability to turn them off altogether.

Thoughts and comments from the standards community are appreciated, either
by post or e-mail.

Thanks in advance.

Dan Moen
Senior Software Engineer
Dow Jones Telerate Systems, Inc.
dmoen@fx.com
--
-= Dan Moen       -=- "Pain? Life IS pain. Anyone who    =-
-= dmoen@fx.com   -=- tells you differently is selling   =-
-= (415)858-7777  -=- something." - Dread Pirate Roberts =-