Table of Contents

Errors and Warnings

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.

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

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: cannot pass U64:1 into String:1 (aka {U32 ..}:1)

... Which is messy, and contains useless information, thereby sacrificing clarity. You could try:

type mismatch U64:1 String:1

... But this does not properly convey its meaning. It sacrifices clarity to achieve a mediocre amount of brevity.

This, however, is ideal:

U64:1 cannot be used as String:1

Notice how it reads like a sentence. This is very important because humans will be using this compiler, and they are accustomed to reading these.