File: systemerror.yo

package info (click to toggle)
c%2B%2B-annotations 13.02.02-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, sid
  • size: 13,576 kB
  • sloc: cpp: 25,297; makefile: 1,523; ansic: 165; sh: 126; perl: 90; fortran: 27
file content (75 lines) | stat: -rw-r--r-- 3,346 bytes parent folder | download | duplicates (4)
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
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
The class tt(std::system_error)hi(system_error) is derived from
tt(std::runtime_error), which in turn is derived from tt(std::exception)

    hi(error_category: required header)
    hi(error_condition: required header)
Before using the class tt(system_error) or related classes the
tthi(system_error) header file must be included.

tt(System_error) exceptions can be thrown when errors occur having
associated (system) em(error values). Such errors are typically associated
with low-level (like operating system) functions, but other types of errors
(e.g., bad user input, non-existing requests) can also be handled. 

In addition to error codes (cf. section ref(ERRORCODE)) and error categories
(covered below) error em(conditions) are distinguished. Error
conditions specify platform independent types of errors like syntax errors or
non-existing requests.

When constructing tt(system_error) objects error codes and error categories
may be specified. First we'll look at the classes tt(error_condition) and
tt(error_category), then tt(system_error) itself is covered in more detail.

Figure ref(SYSERRFIG) illustrates how the various components interact.

    figure(exceptions/systemerror)
        (System_error: associated components)
        (SYSERRFIG)

As shown in figure ref(SYSERRFIG) the class tt(error_category) uses the class
tt(error_condition) and the class tt(error_condition) uses the class
tt(error_category). As a consequence of this circular dependency between these
two classes these classes should be approached as one single class:
when covering tt(error_category) the class tt(error_condition) should be known
and vice versa. This circular dependency among these classes is unfortunate
and an example of bad class design.

As tt(system_error) is eventually derived from tt(exception) it offers the
standard tt(what) member. It also contains an tt(error_code).

In POSIX systems the tt(errno) variable is associated with many, often rather
cryptic, symbols. The predefined tt(enum class errc) attempts to provide
intuitively more appealing symbols. Since its symbols are defined in a
strongly typed enumeration, they cannot directly be used when defining a
matching tt(error_code). Instead, a tt(make_error_code) function converts
    hi(errc (enum))tt(enum class errc) values and values of newly defined
error code enumerations (called ti(ErrorCodeEnum) below) to tt(error_code)
objects.

The ti(enum class errc) defined in the tt(std) namespace defines symbols whose
values are equal to the traditional error code values used by bf(C) but 
describe the errors in a less cryptic way. E.g.,
        verb(    enum class errc 
    {
        address_family_not_supported, // EAFNOSUPPORT
        address_in_use,               // EADDRINUSE
        address_not_available,        // EADDRNOTAVAIL
        already_connected,            // EISCONN
        argument_list_too_long,       // E2BIG
        argument_out_of_domain,       // EDOM
        bad_address,                  // EFAULT
        ...
    };)

Values of tt(ErrorCodeEnums) can be passed to matching tt(make_error_code)
functions. Defining your own tt(ErrorCodeEnum) enumeration is covered in
section ref(ERRCODEENUM).

Now that the general outline has been presented, it's time to have a closer
look at the various components shown in figure ref(SYSERRFIG).