Update 'Error Handling'

Error-Handling.md

@@ -1,5 +1,8 @@
+# Errors and Warnings
 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.
 
+# Propagation
 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.
 
+# Error Messages
 When writing error messages, present the user with something very plain. Do not overload the message with technichal information. Describe what the problem is, and why it was reported. In terms of descriptiveness, be the opposite of the Go compiler. In terms of clarity, be the opposite of g++.