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

Need consistent error handling and formatting #33

Open
TheDan64 opened this issue Apr 28, 2015 · 2 comments
Open

Need consistent error handling and formatting #33

TheDan64 opened this issue Apr 28, 2015 · 2 comments

Comments

@TheDan64
Copy link
Owner

Currently lexer error messages are passed up to the parser, which is probably fine. But I think the parser and code generator should have a format and possibly a supporting format function decided for how to format errors (and eventually warnings). We currently have like 2-3 different functions, I think, all of which are for different formatting?

Also, there should be discussion on whether or not we're handling errors the right way.
Current MO for both the parser and code generator is to just print the error right away and return None. Iirc, the None will just be propagated back to the top level and disregarded. I personally like how this works, but I'm not sure if we should be doing it this way.

The alternative, I suppose, would be to use Rust's Result as intended for error handling, to propagate the error message to the top level and print it there.

I'm kinda more in favor of keeping it as is at the moment, but I'd also like for us to consider any benefits there might be by switching to the Rust practice/standard of using Result for error handling.

@TheDan64
Copy link
Owner Author

TheDan64 commented Jul 14, 2016

Currently being worked on in the better error handling branch.

Here is a WIP checklist for things that this issue covers. Checked items are currently covered by this branch. Not all items may make it into the initial PR so that we can have the basic building blocks in place.

  • Lexer passes up messages to Parser
  • Error and Warning message types
  • Parser/SA/Codegen prints message immediately
  • Codegen's ExprWrapper replaced by more generic wrapper
  • Fault tolerance on messages (see Add fault tolerance on Errors #22)
  • Messages displaying original input string
  • Multiple lines to be displayed (ie cross ref from a different file)

@TheDan64 TheDan64 self-assigned this Jul 14, 2016
@TheDan64
Copy link
Owner Author

TheDan64 commented May 28, 2018

The failure crate seems to be the standard for error handling today

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant