File: usestandard.yo

package info (click to toggle)
c%2B%2B-annotations 12.2.0-2
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 13,044 kB
  • sloc: cpp: 24,337; makefile: 1,517; ansic: 165; sh: 121; perl: 90
file content (53 lines) | stat: -rw-r--r-- 2,735 bytes parent folder | download | duplicates (3)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
Since values of any type may be thrown as exceptions, you may wonder when to
throw values of standard exception types and (if ever) when to throw values of
other types.

Current practice in the C++ community is to throw exceptions only in
exceptional situations. In that respect C++'s philosophy about using
exceptions differs markedly from the way exceptions are used in, e.g., Java,
where exceptions are often encountered in situations C++ doesn't consider
exceptional. Another common practice is to follow a `conceptual' style when
designing software. A nice characteristic of exceptions is that exceptions can
be thrown at a point where your source shows what's happening: throwing an
tt(std::out_of_range) exception is nice for the software maintainer, as
the reason for the exception is immediately recognized.

At the catch-clause the semantical context usually isn't very relevant anymore
and by catching a std::exception and showing its tt(what()) content the
program's em(user) is informed about what happened.

But throwing values of other types can also be useful. What about a situation
where you want to throw an exception and catch it at some shallow level?  In
between there may be various levels of software provided by external software
libraries over which the software engineer has no control.  At those levels
exceptions (std::exceptions) could be generated too, and those exceptions
might also be caught by the library's code. When throwing a standard exception
type it may be hard to convince yourself that that exception isn't caught by
the externally provided software. Assuming that no catch-alls are used (i.e.,
tt(catch (...)))  then throwing an exception from the tt(std::exception)
family might not be a very good idea. In such cases throwing a value from a
simple, maybe empty, tt(enum) works fine:
        verb(    enum HorribleEvent 
    {};      

    ... at some deep level:
        throw HorribleEvent{};

    ... at some shallow level:
    catch (HorribleEvent hs)
    {
        ...
    })

Other examples can easily be found: design a class holding a message and
an error (exit) code: where necessary throw an object of that class, catch it
in the catch clause of main's try block and you can be sure that all objects
defined at intermediate levels are neatly destroyed, and at the end you show
the error message and return the exit code embedded in your non-exception
object.

    So, the advice is to use tt(std::exception) types when available, and
clearly do the required job. But if an exception is used to simply bail out
of an unpleasant situation, or if there's a chance that externally provided
code might catch tt(std:exceptions) then consider throwing objects or values
of other types.