Update 'Error Handling'

Error-Handling.md

@@ -1,3 +1,3 @@
-There are two types of errors in the ARF compiler: errors, and warnings, both of which are provided by `infoerr`. Operations can emit multiple warnings, which should be immediately printed and not stored anywhere (TODO: this is possibly a bad idea. It may be better to keep a running list of them and print them all out at the end). Errors, on the other hand, should be returned as Go `error` values from methods. The occurrence of an error should halt the entire compilation process. Warnings *advise* the user about things that may cause problems or seem unintentional, whereas errors inform the user that the code they have written is erroneous and cannot be compiled.
+There are two types of errors in the ARF compiler: errors, and warnings, both of which are provided by `infoerr`. [Operations](How-to-Parse) can emit multiple warnings, which should be immediately printed and not stored anywhere (TODO: this is possibly a bad idea. It may be better to keep a running list of them and print them all out at the end). Errors, on the other hand, should be returned as Go `error` values from methods. The occurrence of an error should halt the entire compilation process. Warnings *advise* the user about things that may cause problems or seem unintentional, whereas errors inform the user that the code they have written is erroneous and cannot be compiled.
 
 When an error bubbles up to the actual program that is driving the compilation code, it should simply print the error by passing it to a `fmt` print function, or by calling its `Error()` method. It should not attempt to cast the error to an `infoerr.Error` struct, because there is a chance it might not be.