> One issue with Zig's approach is due to its error value inference system, it's very difficult to know what possible errors values a procedure returns just from __reading__ the code (assuming `!T` or `anyerror!T` is used), you have to compile the code in order to determine that. This may be okay for a single developer, but if you are on a larger team you are now either relying on external documentation (which Zig can provide) or the compiler telling you this. With a specific (error) set this is not a problem because it's explicit to the reader.
While I see your point that this should ideally have been fixed at the language level, this is still solvable with a style guide and a linter that lets you forbid using !T / anyerror!T, right?
> The purpose of the programmer exists at the time of writing the software, and so errors in respect to that purpose are well-defined in a contained manner. A bug is an error relative to the programmer's purpose in writing the software. An error relative to programmer's purpose that is caused by the software not being executed as described in the source code is a compiler or a hardware bug. These well-defined error classes are categorically different from errors relative to the purpose of an arbitrary future software user, which is the focus of this article.
I'm a bit confused by this part of the abstract. Doesn't the focus on user error completely remove the relevance to programmers, who are more interested in the first "well-defined" class of errors?
While I see your point that this should ideally have been fixed at the language level, this is still solvable with a style guide and a linter that lets you forbid using !T / anyerror!T, right?
> The purpose of the programmer exists at the time of writing the software, and so errors in respect to that purpose are well-defined in a contained manner. A bug is an error relative to the programmer's purpose in writing the software. An error relative to programmer's purpose that is caused by the software not being executed as described in the source code is a compiler or a hardware bug. These well-defined error classes are categorically different from errors relative to the purpose of an arbitrary future software user, which is the focus of this article.
I'm a bit confused by this part of the abstract. Doesn't the focus on user error completely remove the relevance to programmers, who are more interested in the first "well-defined" class of errors?