lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] "Alert" messages [Was: Code review: product editor]


From: Greg Chicares
Subject: Re: [lmi] "Alert" messages [Was: Code review: product editor]
Date: Mon, 05 Mar 2007 13:47:19 +0000
User-agent: Thunderbird 1.5.0.4 (Windows/20060516)

On 2007-3-5 10:33 UTC, Evgeniy Tarassov wrote:
> On 3/3/07, Greg Chicares <address@hidden> wrote:
>>
>>   throw "Unreachable--silences a compiler diagnostic.");
>> Self documenting, and no <stdexcept> dependency. I think I
>> like this best; have you any other suggestions?
> 
> Another fancy way of explicitly telling the compiler that
> fatal_error() (after an LMI_FLUSH) throws, could be to add 'throw'
> just in front of fatal_error(), like so:
> 
> throw fatal_error()
>    << "Some diagnostic message"
>    << LMI_FLUSH
>    ;

That's clever. I would never have thought of it.

> The syntax is unusual but explicitly points the reader and a compiler
> to the fact that the expression forces the workflow to exit the
> context.
> IIRC the expression being thrown must have a copy constructor.

Yes, I think we'd want to add a copy ctor, which would make
the 'alert' classes more complicated.

> If we do it uniformly for every alert.?pp facility, then someone (like
> me :)) could mistakenly write:
>  throw warning() << "A warning" << LMI_FLUSH;
> which is incorrect and will _not_ be detected at compile time. But the
> bright side is that such an error will only turn warning() into a
> fatal_error().

That's another disadvantage. I've grown accustomed to thinking
that the 'alert' functions are substitutable, e.g., that
  s/fatal_error/warning/
is reliably safe; and it seems useful to keep them so.

I guess this idea's disadvantages outweigh the extra terseness
that it offers, but thanks for sharing it anyway, because it's
intriguing.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]