fspl/arf
fspl/arf
Archived
1
1
Fork 0
Code Issues 7 Pull Requests Packages Projects Releases Wiki Activity

Update 'Error Handling'

Sasha Koshka 2022-10-12 07:02:11 +00:00
parent 119fe56411
commit fb12dc478e
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
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.
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.