RPCSX/llvm
1
0
Fork 0
mirror of https://github.com/RPCSX/llvm.git synced 2025-04-03 16:51:42 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[docs] Fix a few more Error docs formatting issues.

Browse Source 
Thanks to Pete Cooper for the review.



git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285136 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Lang Hames 2016-10-25 22:35:55 +00:00
parent 98711e2ac8
commit 94e5282d34
1 changed files with 6 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
docs/ProgrammersManual.rst
View File

@ -586,7 +586,7 @@ code (especially command line tools) this can be a reasonable approach. Calling
``exit`` upon encountering an error dramatically simplifies control flow as the ``exit`` upon encountering an error dramatically simplifies control flow as the
error no longer needs to be propagated up the stack. This allows code to be error no longer needs to be propagated up the stack. This allows code to be
written in straight-line style, as long as each fallible call is wrapped in a written in straight-line style, as long as each fallible call is wrapped in a
check and call to exit. The ``ExitOnError``` class supports this pattern by check and call to exit. The ``ExitOnError`` class supports this pattern by
providing call operators that inspect ``Error`` values, stripping the error away providing call operators that inspect ``Error`` values, stripping the error away
in the success case and logging to ``stderr`` then exiting in the failure case. in the success case and logging to ``stderr`` then exiting in the failure case.
@ -642,7 +642,7 @@ this, use the named constructor idiom and return an ``Expected<T>``:
class Foo { class Foo {
public: public:

 static Expected<Foo> Create(Resource R1, Resource R2) { static Expected<Foo> Create(Resource R1, Resource R2) {
Error Err; Error Err;
Foo F(R1, R2, Err); Foo F(R1, R2, Err);
if (Err) if (Err)
@ -678,7 +678,7 @@ Propagating and consuming errors based on types
In some contexts, certain types of error are known to be benign. For example, In some contexts, certain types of error are known to be benign. For example,
when walking an archive, some clients may be happy to skip over badly formatted when walking an archive, some clients may be happy to skip over badly formatted
object files rather than terminating the walk immediately. Skipping badly object files rather than terminating the walk immediately. Skipping badly
formatted objects could be achieved using an elaborate handler method, But the formatted objects could be achieved using an elaborate handler method, but the
Error.h header provides two utilities that make this idiom much cleaner: the Error.h header provides two utilities that make this idiom much cleaner: the
type inspection method, ``isA``, and the ``consumeError`` function: type inspection method, ``isA``, and the ``consumeError`` function:
@ -687,12 +687,13 @@ type inspection method, ``isA``, and the ``consumeError`` function:
Error walkArchive(Archive A) { Error walkArchive(Archive A) {
for (unsigned I = 0; I != A.numMembers(); ++I) { for (unsigned I = 0; I != A.numMembers(); ++I) {
auto ChildOrErr = A.getMember(I); auto ChildOrErr = A.getMember(I);
if (auto Err = ChildOrErr.takeError()) if (auto Err = ChildOrErr.takeError()) {
if (Err.isA<BadFileFormat>()) if (Err.isA<BadFileFormat>())
consumeError(std::move(Err)) consumeError(std::move(Err))
else else
return Err; return Err;
auto &Child = *ChildOrErr; }
auto &Child = *ChildOrErr;
// do work // do work
} }
return Error::success(); return Error::success();