From fb12dc478e86363f38a9cf0016e8ffa8c2adce2d Mon Sep 17 00:00:00 2001 From: Sasha Koshka Date: Wed, 12 Oct 2022 07:02:11 +0000 Subject: [PATCH] Update 'Error Handling' --- Error-Handling.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Error-Handling.md b/Error-Handling.md index 993935f..0fd6fa9 100644 --- a/Error-Handling.md +++ b/Error-Handling.md @@ -1,3 +1,5 @@ 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. \ No newline at end of file +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. + +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. \ No newline at end of file