RPCSX/llvm
1
0
Fork 0
mirror of https://github.com/RPCSX/llvm.git synced 2025-03-02 09:58:06 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

[docs] Fix a couple of typos in the new Error docs.

Browse Source 
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@285133 91177308-0d34-0410-b5e6-96231b3b80d8
This commit is contained in:
Lang Hames 2016-10-25 22:22:48 +00:00
parent ed5107d663
commit c468b9c369
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
docs/ProgrammersManual.rst
View File

@ -504,7 +504,7 @@ StringError
Many kinds of errors have no recovery strategy, the only action that can be Many kinds of errors have no recovery strategy, the only action that can be
taken is to report them to the user so that the user can attempt to fix the taken is to report them to the user so that the user can attempt to fix the
environment. In this case representing the error as a string makes perfect environment. In this case representing the error as a string makes perfect
sense. LLVM provides the ``StringError class for this purpose. It takes two sense. LLVM provides the ``StringError`` class for this purpose. It takes two
arguments: A string error message, and an equivalent ``std::error_code`` for arguments: A string error message, and an equivalent ``std::error_code`` for
interoperability: interoperability:
@ -582,7 +582,7 @@ Using ExitOnError to simplify tool code
""""""""""""""""""""""""""""""""""""""" """""""""""""""""""""""""""""""""""""""
Library code should never call ``exit`` for a recoverable error, however in tool Library code should never call ``exit`` for a recoverable error, however in tool
code (especially comamnd line tools) this can be a reasonable approach. Calling 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