Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Bring types result/error to Spicy and flesh them out further #90

Closed
bbannier opened this issue Apr 6, 2020 · 1 comment · Fixed by #1757
Closed

Bring types result/error to Spicy and flesh them out further #90

bbannier opened this issue Apr 6, 2020 · 1 comment · Fixed by #1757
Assignees
@rsmmr
Labels
Cleanup

Comments

@bbannier
Copy link
Member

bbannier commented Apr 6, 2020 •
edited
Loading

Spicy doesn't have the result and error types yet that HILTI offers. Need to bring them to Spicy, and also review how/if the runtime library for both HILTI and Spicy uses them currently for return values from functions and methods. Generally, the goal is to use result wherever reasonable for signaling an error. It should be preferred over exceptions where possible; and also over plain boolean signaling just success/failure (can use result<void> for that).
@bbannier
Copy link
Member Author

bbannier commented Apr 6, 2020

changed title from {-Review usage of result in runtime library-} to {+Bring types result/error to Spicy and flesh them out further+}

@rsmmr rsmmr removed HILTI labels Apr 24, 2020
@rsmmr rsmmr self-assigned this Jun 10, 2024
rsmmr added a commit that referenced this issue Jun 10, 2024
@rsmmr
Expose result and error types to Spicy to facilitate error handling.
de5a296 
The `result` and `error` types were already implemented internally
HILTI-side, but not yet available to Spicy users.

Example usage, with draft/proposed syntax:

```
function foo() : result<int64> {
    ...
    if ( everything_is_ok )
        return 42;
    else
        return error"Something went wrong.";
}

if ( local x = foo() )
    print "result: %s " % *x;
else
    print "error: %s " % x.error();
```

The main catch is syntax: `result` and `error` are pretty common
words, so making them keywords is a bit risky in terms of backwards
compatibility. However, `result` is probably a bit less common than
`error`, so the proposal is this:

- `result<T>` becomes the new type for wrapping a value of type `T` or
  an error value, with `result` becoming a full keyword (i.e., can't
  be used elsewhere).

- `error"MSG"` becomes the constructor for an `error` value with the
  given message. However, `error` does not become a keyword, and
  we don't provide a way to refer to the `error` type directly (e.g.,
  you can't write `local x : error;`

An alternative would be renaming the types (e.g., `expected` instead
of `result`; `error_value` instead of `error`), but not convinced
that's better.

TODO:
    - Finalize docs once we have settled on syntax.

Closes #90.
Closes #1733.
@bbannier bbannier linked a pull request Jun 11, 2024 that will close this issue
Expose result and spicy::Error types to Spicy to facilitate error handling. #1757
Merged
@rsmmr rsmmr closed this as completed in 529521f Jun 13, 2024
mmguero added a commit to mmguero-dev/icsnpp-synchrophasor that referenced this issue Aug 6, 2024
@mmguero
zeek/spicy#90 made 'result' a type, so renaming result variables to r…
a1577f1 
…esultRec to fix syntax error ('syntax error, unexpected RESULT, expecting identifier or scoped identifier')
@mmguero mmguero mentioned this issue Aug 6, 2024
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rsmmr rsmmr

Labels
Cleanup
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Expose result and spicy::Error types to Spicy to facilitate error handling. zeek/spicy
2 participants
@bbannier @rsmmr