Merge pull request #860 from jayschwa/patch-1

doc: fix typo and tighten wording in error sections
This commit is contained in:
Andrew Kelley 2018-03-25 23:31:12 -04:00 committed by GitHub
commit c0a69a5075
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23

View File

@ -2864,18 +2864,18 @@ const err = (error {FileNotFound}).FileNotFound;
assert to make sure the error value is in fact in the destination error set.
</p>
<p>
The global error set should generally be avoided when possible, because it prevents
the compiler from knowing what errors are possible at compile-time. Knowing
the error set at compile-time is better for generated documentationt and for
helpful error messages such as forgetting a possible error value in a {#link|switch#}.
The global error set should generally be avoided because it prevents the
compiler from knowing what errors are possible at compile-time. Knowing
the error set at compile-time is better for generated documentation and
helpful error messages, such as forgetting a possible error value in a {#link|switch#}.
</p>
{#header_close#}
{#header_close#}
{#header_open|Error Union Type#}
<p>
Most of the time you will not find yourself using an error set type. Instead,
likely you will be using the error union type. This is when you take an error set
and a normal type, and create an error union with the <code>!</code> binary operator.
An error set type and normal type can be combined with the <code>!<code>
binary operator to form an error union type. You are likely to use an
error union type more often than an error set type by itself.
</p>
<p>
Here is a function to parse a string into a 64-bit integer:
@ -6033,4 +6033,3 @@ hljs.registerLanguage("zig", function(t) {
</script>
</body>
</html>