Allow returning a value with an error #2647
Comments
|
I see potential in that. A world where error sets are just regular unions, but given all the syntax-level amenities of today's errors. // a regular-ass type
const InvalidChar = struct {
pos: usize,
};
// an error set containing different types
const ParseError = error {
InvalidChar: InvalidChar,
Overflow, // void
};
// merge like ya would today
const Error = ParseError || error{OutOfMemory};
fn f() void {
parse(something) catch |err| switch (err) {
.InvalidChar => |e| warn("bad character at {}", e.pos),
.Overflow => warn("overflow"),
.OutOfMemory => warn("out of memory"),
};
}Taking it further, perhaps all today's good stuff about errors could be applied to any type, not just unions. Maybe the const SomeError1 = error struct {
val: usize,
reason: []const u8,
};
const SomeError2 = error union(enum) {
OutOfOrder,
OutOfBounds,
OutOfIdeas,
};
// today's, which is sugar for above
const SomeError3 = error {
ResourceExhausted,
DeadlineExceeded,
};Because you could now "bloat" an error set with types of larger size, this might affect how strongly use of the global error set is discouraged. |
|
I remember seeing this proposed before but I can't find the issue for it. Maybe it was only on IRC? |
andrewrk
added
the
proposal
|
Thank you @CurtisFenner for a well written proposal |
|
This is just a tagged union. And as they seem so useful, maybe we can add anonymous structs, so we can just use tagged unions instead of multiple return values. Don't worry about the optimizations here. The compiler can handle that. |
|
There's a previous issue here #572 (just for the record) |
|
because errors are assigned a unique value, how about allowing for tagged unions to use errors as the tag value? this would avoid adding new syntax to language and making this feature consistent with other constructs in the language. this tangentially relies on #1945. /// stolen from above
const ParseError = union(error) {
InvalidChar: usize,
Overflow, // equivalent to `Overflow: void`
};
pub fn parseU64(buf: []const u8, radix: u8) ParseError!u64 {
// ......
if (digit >= radix) {
return error{ .InvalidChar = index };
}
// ......
}
test "parseU64" {
if (parseU64(str, 10)) |number| {
// ......
} else |err| switch (err) {
error.Overflow => {
// ......
},
error.InvalidChar => |index| {
// ......
}
}
} |
|
Agreeing with @emoki I'd like some syntactic sugar for multiple arguments to an error switch, if the type is defined in the same tagged union: |
|
I think what @emekoi suggested is excellent, as it removes the need for extra syntax and sidesteps the issues of increasing the size of |
I assume this should be: return ParseError{ .InvalidChar = index };Otherwise I love the idea! |
|
that's what i wasn't sure about. would you still have to explicitly name the error even when using an inferred error set? or would you just use |
|
Not a proposal, but something possible currently: here's a variation on OP's "Workaround 2" (the out parameter). A struct member instead of an "out" parameter. It's still not perfect, but this or Workaround 2 is still the most flexible as they make it possible to allocate memory for the error value (e.g. a formatted error message). const Thing = struct {
const ErrorInfo = struct {
message: []u8,
};
error_info: ?ErrorInfo,
// `allocator` could also be a parameter of an init function
fn doSomething(self: *Thing, allocator: ...) !void {
if (bad thing 1) {
self.error_info = ErrorInfo {
.message = try ...allocate a string...,
};
return error.ThingError;
} else if (bad thing 2) {
self.error_info = ErrorInfo {
.message = try ...allocate a different string...,
};
return error.ThingError;
} else {
// happy
}
}
};
fn caller() void {
var thing = Thing.init();
defer thing.deinit(); // free allocated stuff in error_info if present
thing.doSomething(some_allocator) catch |err| {
switch (err) {
error.ThingError => {
// this `.?` is the smelliest part of this idea
std.debug.warn("error: {}\n", thing.error_info.?.message);
},
else => {
// e.g. an OOM error from when we tried to alloc for the error message
std.debug.warn("some other error\n");
},
}
return;
}
std.debug.warn("success\n");
}This might be a solution for std InStream and OutStream which currently have that annoying generic error parameter? Also, for parsers and line numbers specifically, you don't need to include the line number in the error value itself. Just maintain it in a struct member and the caller can pull it out when catching. If these struct members aren't exclusive to failed states, then there's no smell at all here. const Parser = struct {
...
line_index: usize,
parse(self: *Parser) !?Token {
// continually update line_index, return a regular zig error if something goes wrong
}
}; |
|
I like @emekoi's suggestion here, but I'll note that I'd like to be able to have |
|
I guess it would actually be |
|
in your example |
|
I think the issue here can be summarized by noting that zig has 2 concepts that are tied together that probably don't need to be.
Zig has some nice constructs that make error control flow easy to work with ( Maybe Zig should be able to infer an error set that includes any type, not just error codes? fn foo() !void{
if (...)
return error SomeStruct.init(...);
if (...)
return error.SomeErrorCode;
} |
|
this c++ Proposal is so cool with this zig Proposal, so maybe a consider.l |
|
I find that the boost library |
|
I additionally propose that coercing a |
|
Is this not typically a job for some kind of interfaces, i.e. allow anything that implements |
|
Here's a pattern that I would consider to be an alternative to this proposal: Lines 717 to 826 in 5709737 I think it's quite reasonable. Edit: here's usage example at the callsite: zig/src-self-hosted/stage2.zig Lines 677 to 708 in 5709737 |
|
The problem with returning a value with an error, is that it is the same as returning a polymorphic type, and defining that return type inside the function, instead of in the function signature. While I think we still need inferred return types (#447) for some things, this is an advanced feature, and fancier patterns, like the example, should be required in order to utilize these features. We also need inferred types as a way of sneaking in multiple return values (through the anonymous structs we already have), which LLVM supports, but in C requires an ugly one-use-but-defined struct (and where the C ABI layout of that struct is ignored by the optimization pass). |
|
I think it's reasonable, but I think it could be better by making minimal changes to the language. Specifically, I think Zig is already expressive enough to more tightly reflect the function's interface in its type signature; we just need to apply the right already-existing features. My two main complaints with what you can currently achieve:
An error set like This (modified) proposal is to optionally transform the "error set" concept into an "error union" concept -- noting that a tagged union with all void field types is essentially the same thing as a enum; ie, we have just strengthened an existing concept (error sets) to another existing concept (tagged unions). I don't think it's necessary to automatically generate the union, as emekoi suggested earlier -- we just use The example would look something like pub const DiagnosticsErr = union(error) {
UnknownCpuFeature: ?[]const u8,
MissingArchitecture: void,
// same as UnknownCpu: void
UnknownCpu,
}
pub fn parse(args: ParseOptions) !Target { // infer DiagnosticsErr!Target
......
// equivalent to `return DiagnosticsErr{.MissingArchitecture={}};`
return error.MissingArchitecture;
......
return DiagnosticsErr{.UnknownCpuFeature = feature_name};
}
var result = Target.parse(.......) catch |err| switch (err) {
error.UnknownCpuFeature => |unknown_feature_name| {
......
},
else => |e| return e,
}I think this is a relatively small change to the language (since it re-uses existing concepts and is totally backwards compatible) to make some situations much clearer without any additional runtime/compiletime cost. |
|
related: #786 |
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *ErrCtx`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `ErrCtx` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on "\x00") and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.split_rev`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *ErrCtx`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `ErrCtx` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.split_rev`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.split_rev`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.split_rev`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.split_rev`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitRev`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitRev`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitReversed`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitBackwards`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'žemas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitBackwards`.
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'Žvangalas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitBackwards`.
* mem: refactor tests of split()
- add a few cases for .rest()
- use expectEqualSlices()
* mem: add splitBackwards
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'Žvangalas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitBackwards`.
* mem: refactor tests of split()
- add a few cases for .rest()
- use expectEqualSlices()
* mem: add splitBackwards
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'Žvangalas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitBackwards`.
* mem: refactor tests of split()
- add a few cases for .rest()
- use expectEqualSlices()
* mem: add splitBackwards
Over the last couple of weeks weeks I needed to iterate over a
collection backwards at least twice. Do we want to have this in stdlib?
If yes, click "Merge" and start using today! Free shipping and returns
(before 1.0).
Why is this useful?
-------------------
I need this for building an error wrapper: errors are added in the
wrapper from "lowest" level to "highest" level, and then printed in
reverse order. Imagine `UpdateUsers` call, which needs to return
`error.InvalidInput` and a wrappable error context. In Go we would add a
context to the error when returning it:
// if update_user fails, add context on which user we are operating
if err := update_user(user); err != nil {
return fmt.Errorf("user id=%d: %w", user.id, err)
}
Since Zig cannot pass anything else than u16 with an error (ziglang#2647), I
will pass a `err_ctx: *Err`, to the callers, where they can, besides
returning an error, augment it with auxiliary data. `Err` is a
preallocated array that can add zero-byte-separated strings. For a
concrete example, imagine such a call graph:
update_user(User, *Err) error{InvalidInput}!<...>
validate_user([]const u8, *Err) error{InvalidInput}!<...>
Where `validate_user` would like, besides only the error, signal the
invalid field. And `update_user`, besides the error, would signal the
offending user id.
We also don't want the low-level functions to know in which context they
are operating to construct a meaningful error message: if validation
fails, they append their "context" to the buffer. To translate/augment
the Go example above:
pub fn validate_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
const name = user.name;
if (!ascii.isAlpha(name)) {
err_ctx.print("name '{s}' must be ascii-letters only", .{name});
return error.InvalidInput;
}
<...>
}
// update_user validates each user and does something with it.
pub fn update_user(err_ctx: *Err, user: User) error{InvalidInput}!void {
// validate the user before updating it
validate_user(user) catch {
err_ctx.print("user id={d}", .{user.id});
return error.InvalidInput;
};
<...>
}
Then the top-level function (in my case, CLI) will read the buffer
backwards (splitting on `"\x00"`) and print:
user id=123: name 'Žvangalas' must be ascii-letters only
To read that buffer backwards, dear readers of this commit message, I
need `mem.splitBackwards`.
|
Some examples where returning a value with an error would be helpful: If Lines 189 to 226 in 94aeb6e If If a developer did var body_file = std.fs.openFileAbsoluteZ(absolute_path_, .{ .mode = .read_only }) catch |err| {
Output.printErrorln("<r><red>{s}<r> opening file {s}", .{ @errorName(err), absolute_path });
Global.exit(1);
}; |
|
I appreciate that this is a difficult issue (I think Spec's explanation on the Zig Discord was helpful for me understanding the challenges), but I really feel the current state of things is unsatisfactory. I just spent way longer than I should have to debugging an issue of my project's build not working on Windows given that all I had to work with from the zig compiler was an (sorry for not being able to propose a concrete solution here, I just felt the need to bump this issue with a use case after a particularly unpleasant debugging experience) Footnotes
|
|
I think this has already been captured, but I'm dealing with error values that have resources that must be freed. I'm not sure how this would work with Specifically, I've written a driver for duckdb. When failing to execute a query, duckdb provides a detailed error message. That message is valid until the underlying prepared statement is freed. Whether I dupe the error message or keep a reference to the prepared statement, I need to free something. I'm using a Result / tagged union, but it's a bit cumbersome to consume. |
|
I agree that something to this affect would be great, particularly in the instance of failed parsing, writing to file, etc... I have also experience similar opaque error messages when parsing json with no hint of where in the json file the error occurred |
|
I was thinking along the lines of @marler8997's suggestions, but from a perspective that this approach can actually solve the problem of merging conflicting error sets (which is an unsolved problem in the OP's proposal, and I find it a bit difficult to accept it to be unsolved). So, once we allow other types to be used as members of error sets, there is no problem with a conflict, since each type is globally unique in a natural way. The syntax could look e.g. like follows (I do not insist on this specific form, which is based on @marler8997's one, this is just an example) const MyErrorSet = error {
SomeErrorId,
AnotherErrorId,
error ErrorIdWithPayload,
};
const ErrorIdWithPayload = struct {
payload_field1: []const u8,
payload_field2: usize,
};
fn fail() MyErrorSet!void {
return error ErrorIdWithPayload{ .payload_field1 = "", .payload_field2 = 0 };
}
fn func() void {
fail() catch |err| switch(err) {
error.SomeErrorId, error.AnotherErrorId => {},
error ErrorIdWithPayload => |payload| {
std.debug.print("{s} {}\n", .{ payload.payload_field1, payload.payload_field2 });
}
};
}Notice that, differently from const fail_example = @import("fail_example.zig");
fn func() void {
fail_example.fail() catch |err| switch(err) {
error.SomeErrorId, error.AnotherErrorId => {},
error fail_example.ErrorIdWithPayload => |payload| {
std.debug.print("{s} {}\n", .{ payload.payload_field1, payload.payload_field2 });
}
};
} |
and others
Sometimes when a function fails, there is extra information that you have on hand that may help the caller respond to the problem or produce a diagnostic. For example, in the
parseU64example by andrewrk here,it would be useful for the function could return the position of the invalid character so that the caller could produce a diagnostic message.
Because Zig treats
errortypes specially, when using errors you get a bunch of nice features, such as!error-set inference,try/catch, anderrdefer; you currently lose these features if you want to return extra diagnostic information since that information is no longer an error type.While something like index-of-bad-character is less useful for parsing an integer, getting "bad character" with no location when parsing a 2KiB JSON blob is very frustrating! -- this is the current state of the standard library's JSON parser.
There are currently two workarounds possible today to let this extra information get out, neither of which are very ergonomic and which work against Zig's error types:
Workaround 1: Return a tagged union
You could explicitly return a tagged union that has the extra information:
This is unfortunate in a number of ways. First, because
InvalidCharis no longer anerror, you cannot propagate/handle the failure withtry/catch. Second, because theInvalidCharcase is no longer anerror, you cannot useerrdeferto cleanup partially constructed state in the parser. Finally, calling the function is made messy because it can fail in two separate ways -- either in the error union, or in the explicitly returned union. This means calls that distinguish different errors (as opposed to just propagating withtry) need nestedswitches.Workaround 2: Write to an out parameter
You could also leave the error set alone, and instead expand the contract of
parseU64to write to an out parameter whenever it returns aInvalidCharerror:However, this makes the function's interface much messier: it now includes mutation, and it makes it impossible to indicate that it's being called in such a way that it cannot fail, since the pointer parameter is required (where previously a
catch unreachablecould handle). Also, it won't be immediately obvious which out parameters are associated with which errors, especially if inferred error sets are being used. In particular, it gives libraries writes the opportunity to sometimes re-use out parameters (in order to prevent function signatures from growing out of hand) and sometimes not (they at least cannot when the types aren't the same).Proposal: Associate each error with a type
EDIT: Scroll down to a comment for a refreshed proposal. It looks essentially the same as here but with a bit more detail. The primary difference is not associating errors with value types, but an error within a particular error-set with a type. This means no changes to the
anyerrortype are necessary.I propose allowing a type to be associated with each error:
The value returned would be available in
switchs:This allows a function which can fail in multiple ways to associate different value types with different kinds of failures, or just return some plain errors that worked how they did before.
With this proposal, the caller can use inferred error sets to automatically propagate extra information, and the callsite isn't made messy with extra out-parameters/an extra non-error failure handling switch. In addition, all of the features special to errors, like
errdeferandtry/catch, continue to work.Errors in the global set would now be associated with a type, so that the same error name assigned two different types would be given different error numbers.
I'm not sure what happens when you have an error set with the same name twice with different types. This could possibly be a limited case where "overloading" a single name is OK, since instantiating an error is always zero-cost, but I'll ask what others think.
I'm fairly new to Zig, so some of the details may not be quite right, but hopefully the overall concept and proposal makes sense and isn't unfixably broken.
The text was updated successfully, but these errors were encountered: