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.

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

Standardize error structures. #103

Open
faultyserver opened this issue Dec 29, 2017 · 1 comment
Open

Standardize error structures. #103

faultyserver opened this issue Dec 29, 2017 · 1 comment
Labels
feature-request Any request for a new feature of the language. Includes both syntax and library features. stdlib Any issue relating to the standard library (Myst code) of Myst.

Comments

@faultyserver
Copy link
Member

One of the "marketed features" of Myst is that any value can be raised as an exception. This is great for user-land code, letting raise act like a more powerful break, but can be a nightmare for consistency and extendability in libraries and frameworks.

I see a few aspects to this:

  • Add core error types to the native library. This would include NoClauseError, MatchError, ParseError, etc.
  • Add standard library error types where appropriate. This would include things like FileNotFound, DivideByZero, etc. (these are examples. Actual errors will probably differ).
  • Refactor existing code to use these types (see Only raise RuntimeErrors from the Interpreter #98 for a start).

Additionally, an important part of rescuing errors is knowing where the error came from. With normal values as exceptions, this won't always be possible (e.g., integers don't have a callstack attached to them). For this, I have two ideas:

  • Add an optional second parameter for rescue that captures cause information separately. This would be similar to the result of the caller method that Ruby provides. This feels like it would need a distinguishing syntax to avoid confusion with passing multiple values:

    def foo
    rescue error, cause
      # `cause` includes the callstack of the error and location info.
    end
    
  • Assume a standard method name for getting callstack info in a rescue. This is implicit and I don't particularly like it, but avoids the confusion from above:

    def foo
    rescue error
      cause.callstack.size
      # `cause` is basically a magic constant like `__LINE__`.
    end
    

I'm not super excited by either of those, but I'm leaning towards the first, at least as a temporary implementation.

@faultyserver faultyserver added feature-request Any request for a new feature of the language. Includes both syntax and library features. stdlib Any issue relating to the standard library (Myst code) of Myst. labels Dec 29, 2017
@faultyserver faultyserver added this to the Next milestone Dec 29, 2017
faultyserver added a commit to faultyserver/myst that referenced this issue Dec 30, 2017
…to RuntimeErrors, move nativelib specs into Myst.

This commit starts work on converting all errors raised by the interpreter into rescue-able RuntimeErrors. Specifically, this commit addresses all instances of `raise` in the Native Library, using the new `__raise_runtime_error` to raise an appropriate message.

When myst-lang#103 is addressed, these errors will change to proper error structures (rather than strings), but that is a future effort.

Some other instances of `raise` were also converted in the process of this commit.
@faultyserver
Copy link
Member Author

I think having an expectation that rescues that need cause information use some sort of type restriction (potentitally just Exception, though ideally more exact based on the context) would be fine.

My other thought was making rescue require a subclass of Exception, then adding catch for other kinds of values, but I feel like that would cause more confusion than it's worth.

@faultyserver faultyserver removed this from the Next milestone Jan 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request Any request for a new feature of the language. Includes both syntax and library features. stdlib Any issue relating to the standard library (Myst code) of Myst.
Projects
None yet
Development

No branches or pull requests

1 participant