Topic: standard exception classes


Author: Ryszard Kabatek <kabatek@chemie.uni-halle.de>
Date: 1998/03/06
Raw View
Hi!

The std::exception class contains
a default (1) and
a copy constructor (2)
and an overloaded assignment operator (3),
but no constructor that takes a string parameter (4).

The other standatd exception classes, which inherites from
the std::exception have only the (4).

That means, I can copy an std::exception object
(what data should it copy?),
but not an (for example) std::logic_error object!

It's very strange.

Moreover they haven't destructors, how to inherite from them?

--
Ryszard Kabatek     ,,,
                   (o o)
---------------o00--(_)--00o---------------
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: Valentin Bonnard <bonnardv@pratique.fr>
Date: 1998/03/06
Raw View
Ryszard Kabatek wrote:

> The std::exception class contains
> a default (1) and
> a copy constructor (2)
> and an overloaded assignment operator (3),
> but no constructor that takes a string parameter (4).
>
> The other standatd exception classes, which inherites from
> the std::exception have only the (4).

See 17.2.2.2 [lib.functions.within.classes]:

1 For  the  sake  of  exposition, Clauses _lib.language.support_ through
  _lib.input.output_ do not describe copy constructors, assignment oper-
  ators,  or  (non-virtual) destructors with the same apparent semantics
  as those that can be generated by default (_class.ctor_, _class.dtor_,
  _class.copy_).

> Moreover they haven't destructors, how to inherite from them?

In C++ there no such thing a class without a destructors, or copy ctor.

The dtor of class exception is virtual.

but:

the problems I see is that:

- the lifetime of exception::what() isn't well-defined
- what() should be pure virtual with no implementation,
  shouldn't it ? or what does exception::what() returns ?

--

Valentin Bonnard                mailto:bonnardv@pratique.fr
info about C++/a propos du C++: http://pages.pratique.fr/~bonnardv/
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: clamage@Eng.Sun.COM (Steve Clamage)
Date: 1998/03/06
Raw View
Ryszard Kabatek <kabatek@chemie.uni-halle.de> writes:

>The std::exception class contains
>a default (1) and
>a copy constructor (2)
>and an overloaded assignment operator (3),
>but no constructor that takes a string parameter (4).

Even if you do not use any of the C++ standard library
explicitly in your code, it is hard to avoid the possibility
of exceptions in programs. Some built-in language constructs
can throw exceptions. Rather than force every C++ program to
require the standard string class, the "exception" base class
was defined so as not to require strings.

Every class has a copy constructor and assignment operator,
whether you declare them or not. Those basic members plus the
default constructor were declared for the exception base class
because they are guaranteed not to throw an exception.

>The other standard exception classes, which inherit from
>the std::exception have only the (4).

>That means, I can copy an std::exception object
>(what data should it copy?),
>but not an (for example) std::logic_error object!

The derived exception classes come into play only if you
use the standard library, in which case it seemed
reasonable to allow the use of strings. Don't forget that
every library class has default and copy ctors and an
assigment operator when they are not explicitly declared,
as explained in the library introductory material.

>Moreover they haven't destructors, how to inherit from them?

The exception base class has a virtual destructor, so the
derived classes do too. That's a basic language rule, and
requires no documentation in the derived class description.

--
Steve Clamage, stephen.clamage@sun.com
---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]





Author: jodle@bix.com (jodle)
Date: 1996/06/24
Raw View
Martin Aupperle (100754.2730@compuserve.com) wrote:
: The standard defines classes logic_error and runtime_error.

: 1.)  A "logic error" is something that can theoretically  be detected
: by statical analysis of the program.  A out_of_range error is such a
: thing. The DWP says: "The class out_of_range defines the type of
: objects thrown as exceptions to report an argument value not in its
: expected range.".

: 2.) A "runtime_error" is something that can be detected only when the
: program actually runs. A range_error is such an error. The DWP says:
: "The class range_error defines the type of objects thrown as
: exceptions to report range errors.".

Obviously, an out_of_range error could be foreseen by the programmer where
a range_error could not.  :)

Let's look at the broader context for a moment.  A runtime error would
likely be associated with an object interacting in an environment which it
does not control.  For example, the object might be trying to read a
stream, oblivious to the fact that the stream is in fact a file on a
floppy disk which the operatore removed prematurely.  The programmer can
foresee the scenario and even develop code to recover from it.  He cannot
write code that will prevent the disk removal or even predict it.

A similar and more relavant scenario is one in which the object is
communicating over a network with another object, say providing some sort
of channelization services.  The server object informs the client object
that there are 32 channels available, and the client for some reason
requests data from channel 90.  That would be, in my opinion, a
range_error rather than an out_of_range error.

That's how I interpret all of this, anyway.


[ 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                             ]





Author: 100754.2730@compuserve.com (Martin Aupperle)
Date: 1996/06/18
Raw View
The standard defines classes logic_error and runtime_error.

1.)  A "logic error" is something that can theoretically  be detected
by statical analysis of the program.  A out_of_range error is such a
thing. The DWP says: "The class out_of_range defines the type of
objects thrown as exceptions to report an argument value not in its
expected range.".

2.) A "runtime_error" is something that can be detected only when the
program actually runs. A range_error is such an error. The DWP says:
"The class range_error defines the type of objects thrown as
exceptions to report range errors.".

Now, where is the difference here? When shall I throw which?

Thank you - Martin

-----------------------------------
Signatures are a waste of bandwidth
-----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]