mirror of
https://gitlab.com/fbb-git/cppannotations
synced 2024-11-16 07:48:44 +01:00
Repaired Typos etc.
git-svn-id: https://cppannotations.svn.sourceforge.net/svnroot/cppannotations/trunk@454 f6dd340e-d3f9-0310-b409-bdd246841980
This commit is contained in:
parent
2e1e6169c8
commit
d35fd10cd8
2 changed files with 9 additions and 9 deletions
|
@ -3,9 +3,10 @@ according to its specifications in the face of exceptions. It is not always
|
|||
easy to realize exception safety. In this section some guidelines and
|
||||
terminology is introduced when discussing exception safety.
|
||||
|
||||
Since exceptions may be generated from within all bf(C++) functions exceptions
|
||||
may be generated in many situations, not all of which will be immediately and
|
||||
intuitively clear. Consider the following function and ask yourself at which
|
||||
Since exceptions may be generated from within all bf(C++) functions,
|
||||
exceptions may be generated in many situations. Not all of these situations
|
||||
will be immediately and intuitively recognized as situations where exceptions
|
||||
can be thrown. Consider the following function and ask yourself at which
|
||||
points exceptions may be thrown:
|
||||
verb(
|
||||
void fun()
|
||||
|
@ -30,8 +31,8 @@ and operator new (#5a) too. But did you realize that this latter exception
|
|||
might not be thrown from tt(::new), but from, e.g., tt(X)'s own overload of
|
||||
tt(operator new)? (#5b)
|
||||
it() tt(cout << (x + *xp)): we might be seduced into thinking that two
|
||||
tt(X) objects are added it doesn't need to be that way. A separate class Y
|
||||
might exist and tt(X) may have a conversion operator tt(operator Y() const),
|
||||
tt(X) objects are added. But it doesn't have to be that way. A separate class
|
||||
Y might exist and tt(X) may have a conversion operator tt(operator Y() const),
|
||||
and tt(operator+(Y const &lhs, X const &rhs), operator+(X const &lhs, Y const
|
||||
&rhs)), and tt(operator+(X const &lhs, X const &rhs)) might all exist. So, if
|
||||
the conversion operator exists, then depending on the kind of overload of
|
||||
|
|
|
@ -48,10 +48,9 @@ value by a very small value;
|
|||
itht(range_error)(std::range_error): a range error should be thrown when
|
||||
an internal computation results in a value exceeding a permissible range;
|
||||
itht(runtime_error)(std::runtime_error): a runtime error should be thrown
|
||||
when a problem is detected the program cannot easily be caught by syntactic
|
||||
analysis of the program but are usually only detected during the program's
|
||||
execution. Example: a non-integral is entered when the program's input expects
|
||||
an integral value.
|
||||
when a problem is encountered that can only be detected while the program is
|
||||
being executed. Example: a non-integral is entered when the program's input
|
||||
expects an integral value.
|
||||
itht(underflow_error)(std::underflow_error): an underflow error should be
|
||||
thrown when an arithmetic underflow is detected. Example: dividing a very
|
||||
small value by a very large value.
|
||||
|
|
Loading…
Reference in a new issue