roc-lang/roc
1
1
Fork 0
mirror of https://github.com/roc-lang/roc.git synced 2024-10-05 06:37:26 +03:00
Code Issues Packages Projects Releases Wiki Activity

Fix typo in tutorial

Browse Source
This commit is contained in:
Richard Feldman 2024-04-28 08:35:44 -04:00
parent 1c83abcb03
commit 1fd7f079c5
No known key found for this signature in database
GPG Key ID: F1F21AA5B1D9E43B
1 changed files with 3 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
www/content/tutorial.md
View File

@ -1630,7 +1630,7 @@ high-quality programs handle errors gracefully. Fortunately, we can do this nice
If we wanted to add the type annotation to `main` that Roc is inferring for it, we would add this annotation:
```roc
main : Task {} [Exit I32, StdoutErr Stdout.Err, StinErr Stdin.Err]
main : Task {} [Exit I32, StdoutErr Stdout.Err, StdinErr Stdin.Err]
main =
```
@ -1638,7 +1638,7 @@ Let's break down what this type is saying:
- `Task` tells us this is a `Task` type. Its two type parameters are just like the ones we saw in `Result` earlier: the first type tells us what this task will produce if it succeeds, and the other one tells us what it will produce if it fails.
- `{}` tells us that this task always produces an empty record when it succeeds. (That is, it doesn't produce anything useful. Empty records don't have any information in them!) This is because the last task in `main` comes from `Stdout.line`, which doesn't produce anything. (In contrast, the `Stdin` task's first type parameter is a `Str`, because it produces a `Str` if it succeeds.)
- `[Exit I32, StdoutErr Stdout.Err, StinErr Stdin.Err]` tells us the different ways this task can fail. The `StdoutErr` and `StdinErr` tags are there becase we used `Stdout.line` and `Stdin.line`. We'll talk about `Exit I32` more in a moment.
- `[Exit I32, StdoutErr Stdout.Err, StdinErr Stdin.Err]` tells us the different ways this task can fail. The `StdoutErr` and `StdinErr` tags are there becase we used `Stdout.line` and `Stdin.line`. We'll talk about `Exit I32` more in a moment.
To understand what the `Exit I32 Str` error means, let's try temporarily commenting out our current `main` and replacing
it with this one:
@ -1666,7 +1666,7 @@ In summary:
### [Handling task failures](#handling-task-failures) {#handling-task-failures}
If the `main` task ends up failing with any other errors besides `Exit` (such as `StdoutErr` or `StdinErr`), then the `basic-cli` platform's automatic error handling will handle them by printing out words taken from the source code (such as "StdoutErr" and "StinErr"), which could lead to a bad experience for people using this program!
If the `main` task ends up failing with any other errors besides `Exit` (such as `StdoutErr` or `StdinErr`), then the `basic-cli` platform's automatic error handling will handle them by printing out words taken from the source code (such as "StdoutErr" and "StdinErr"), which could lead to a bad experience for people using this program!
We can prevent that by gracefully handling the other error types, and then translating them into `Exit` errors so that they affect the program's exit code and don't result in the platform printing anything. A convenient way to make sure we've handled all the other errors is to keep our current type annotation for `main` but restore our old implementation: