-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error handling #53
Comments
Incidentally, I kind of like what lua does with multiple returns, but I don't like the "error last" convention, which makes it easy to discard errors. Hence putting it first. If you really, really want to discard an error, maybe provide an
Similarly, if we enforce the (sensible) rule that functions which return
|
Additionally, it would be cool to have a nice way to express the common idiom "call a function and branch on success, binding a value if successful". Maybe just a straight syntactic sugar:
desugars to the following pseudocode:
Of course, we should be able to do further branches on the error
Or none at all
Though this last one is awkward because e would often be bound to a known (and therefore useless) value. |
An alternative for if you seriously don't care about the error code:
Not to be confused with
... maybe make the expression form be |
We should probably think about our story for this at some point.
We could add generics/templates and discriminated unions and go for a Result type, but that's... a lot.
We could do multiple return. Maybe say that you return your error first, then your value, and provide a syntax...
EDIT: Of course,
err
is a new type... it's one byte wide, has the special value literalok
, and allows 1-255 as literals. You can't do arithmetic with it or assignu8
s to it. If a conditional expression has typeerr
,ok
is considered truthy.The text was updated successfully, but these errors were encountered: