Alexandre Oliva wrote:
>
> Christopher Eltschka writes:
>
> > template<class T> T& operator||(T& t,const MyException& e)
>
> > class OpenFailed: public MyException { /* ... */ }
> > // (this is probably in an included header file)
>
> > myfile=open(file) || OpenFailed(file);
> > // No () needed around assignment, because operator||(t&, const e&)
> > // returns t again.
>
> This has the side-effect of constructing an instance of OpenFailed
> every time a file is opened, no matter whether it is necessary or not.
> If this constructor has important side-effects, this may be highly
> undesirable.

While this is formally correct, the second argument of operator||
has the only purpose to be thrown as exception eventually. And the
constructor of an exception object IMHO should not have important
side-effects anyway (you don't know in which situation this exception
will be thrown)

This leads to another question:

What happens if an exception is thrown during construction of an
object to be used for throw? Like here:

class ThrowOnConstruction
{
public:
  ThrowOnConstruction()
    {
      throw "Sorry - you can't get objects of this type...";
    }
};

void TryToThrow()
{
  try
  {
    throw ThrowOnConstruction();
  }
  catch(const char* s)
  {
    cout << s << endl;
  }
}

g++ 2.7.2.1 throws the string, but for me it would be more natural,
if there would be a double exception leading to an terminate()
call (as the throw "Sorry..." executed when evaluating a
throw expression).
What should the behaviour be according to the standard?


[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]