boostorg/system
1
0
Fork 1
mirror of https://github.com/boostorg/system.git synced 2025-07-29 20:17:13 +02:00
Code Issues Packages Projects Releases Wiki Activity

Change 'wrapping' to 'adapting'

Browse Source
This commit is contained in:
Peter Dimov
2021-11-10 18:52:41 +02:00
parent 292c6825c6
commit 7dce2e3f42
1 changed files with 3 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
doc/system/usage.adoc
View File

@ -675,7 +675,7 @@ if( ec == sys::errc::invalid_argument )
which is what one should generally use for testing for a specific error
condition, as a best practice.
## Wrapping Existing Integer Error Values
## Adapting Existing Integer Error Values
Libraries with C (or `extern "C"`) APIs often signal failure by returning
a library-specific integer error code (with zero typically being reserved
@ -687,7 +687,7 @@ Because the integer error codes are library specific, and in general match
neither `errno` values or system category values, we need to define a
library-specific error category.
### Wrapping SQLite Errors
### Adapting SQLite Errors
We'll take SQLite as an example. The general outline of a custom error
category is as follows:
@ -765,7 +765,7 @@ and we're done. `sqlite3_category()` can now be used like the predefined
categories, and we can put an SQLite error code `int r` into a Boost.System
`error_code ec` by means of `ec.assign( r, sqlite3_category() )`.
### Wrapping ZLib Errors
### Adapting ZLib Errors
Another widely used C library is ZLib, and the portion of `zlib.h` that
defines its error codes is shown below: