Update 'Error Handling'

Error-Handling.md

@@ -5,4 +5,24 @@ There are two types of errors in the ARF compiler: errors, and warnings, both of
 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++.
+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++.
+
+For example, say you wanted to produce an error when a value of one type can't be passed as another type. You could do:
+
+```
+type mismatch of String:1 (aka {U32 ..}:1), U64:1
+```
+
+... Which is messy, and overly long for something that isn't conceptually dense at all. You could try:
+
+```
+mismatch String:1 U64:1
+```
+
+... Which is overly terse and does not properly convey its meaning.
+
+This, however, is ideal:
+
+```
+U64:1 cannot be used as String:1
+```