←back to thread

517 points bkolobara | 2 comments | | HN request time: 0s | source
Show context
aeve890 ◴[] No.45042188[source]
>The code will compile just fine. The Zig compiler will generate a new number for each unique 'error.*'

This is wild. I assume there's at least the tooling to catch this kind of errors right?

replies(3): >>45042403 #>>45042586 #>>45050319 #
arwalk ◴[] No.45042586[source]
The example is a bit dubious. Sure, it compiles just fine, because the author is not using errors properly in zig. Here, he uses the global error set with `error. AccessDenid`, and as stated, it compiles just fine because when you reach the global error set, it's integers all the way down.

If the author had written `FileError.AccessDenid`, this would not have compiled, as it would be comparing with the `FileError` error set.

The global error set is pretty much never used, except when you want to allow a user to provide his own errors, so you allow the method to return `anyerror`.

replies(3): >>45042666 #>>45043035 #>>45043562 #
1. veber-alex ◴[] No.45042666[source]
Why does the compiler decay the FileError and the global error set to an integer? If they were unique types, the if statement would not have compiled.
replies(1): >>45043279 #
2. arwalk ◴[] No.45043279[source]
`FileError.AccessDenied` is a unique value in a unique error set. `error.AccessDenid` has not been defined anywhere and hence is just given an integer value at some point by the compiler.

As I stated before, this error wouldn't even exist in the first place in no codebase ever: look how the method that fails returns a `FileError` and not an `anyerror`

It could be rightly argued that it still shouldn't compile though.