Because I'm on my soapbox, I'll also recommend implementing ToString[1] right off the bat, too. That way you can print out useful error messages immediately.

For example, if your errors are:

  enum RispError {
      /// Syntax error returning line number and char
      SyntaxErr(u32, u32),
      /// Parens not balanced; contains number of parens needed
      UnbalancedParens(usize),
  }

You can impl ToString straight away:

  impl ToString for RispErr {
      fn to_string(&self) -> String {
          match self {
              RispErr::SyntaxErr(l,c) => format!("syntax error at line {}, col {}", l, c),
              RispErr::UnbalancedParens(n) => format!("use your % key more! add {} more paren", n),
          }
      }
  }

Then, when handling the error, you can

  match do_thing() {
      Ok(v) => { ... },
      Err(e) => { // TODO handle error
          println!(e)
      }
  }

where do_thing's signature looks like

  fn do_thing(...) -> Result<T, RispErr>;

It takes the same amount of code, but all your error messages are in the same place, you haven't lost information about them, and refactoring to handle them becomes super easy.

(n.b. I dashed this comment off without actually compiling the above, so please forgive any dumb errors =] )

[1] https://doc.rust-lang.org/std/string/trait.ToString.html

Instead of implementing `ToString` directly, you should implement `Display`. A `ToString` implementation will automatically be added, and you get all the formatting goodness out of the box.

That's a good idea! I don't often impl Display so it didn't even occur to me.

As a Lisp programmer, the way most other languages handle errors make me cringe. How could I even make a decent ice cream sundae without error recovery? But I do enjoy that 'make a Lisp' is a like a sport in every other language.

http://www.lispworks.com/documentation/HyperSpec/Body/f_cerr...

http://www.lispworks.com/documentation/HyperSpec/Body/m_rst_...

Oof, I love this — thank you thenewwazoo!

I gotta get to sleep, but will either update the post or add a note in the morning.

And of course, will do this in all future rust projects :D

Glad to help! I am a huge huge fan of Rust. I'm almost always hanging out on ##rust and ##rust-beginners on Freenode if you want to ask questions synchronously. :)

Use the "?" operator. That way, you only handle errors one time (probably at the root of your program).

See here: https://github.com/omarabid/rust-starter/blob/master/src/mai...

included this as a note in the essay. I think a quick blog post about this approach would be quite useful actually, if you're up for it thenewwazoo!

YAGNI, KISS. Lots of code never ends up caring about differentiating between different error conditions. A lot doesn't even care if the code it called failed - maybe it'll log, but the caller can continue regardless. And for a parser, I'm more likely going to want a struct with file/line info (or a full blown list of context) than a bunch of hardcoded enum cases. Having the enum in place to easily identify refactoring points is nice, but having a bunch of mostly unused variations inside the enum will mostly just distract me, and slow me down, giving me more code to re-understand regardless.

In the cases where I do want to distinguish between error cases, I'd still rather wait until I have the code consuming those error enums to help guide what errors are meaningfully different - evidenced by needing different error handling paths - instead of making every caller decide which of the dozens or hundreds of edge cases they want to be handled which way(s).

There are cases where your approach of distinguishing cases up front would be better - as an example, if you're limited in your ability to refactor due to the interface being part of a public API with semver restrictions to your refactoring - but there's plenty of cases where the author's approach is the correct one, where you should be cringing if you don't see things kept as simple as RispErr.

I feel there's a special type of irony in criticizing a Lisp implementation for not being sufficiently type-safe.

(Or maybe it's just a generic irony ... I can't tell yet.)

Oh, I know. :) I mostly spoke up because of my own journey with Rust, and knowing how important articles like these could be to people new to the language. I totally understand why Stringifying errors is appealing in Rust but breaking the mental habit is harder than learning good habits straight away.

Thanks for the feedback thenewwazoo!

This sounds quite cool -- if you have the time, would you mind giving me a quick example? Want to make sure I have a full understanding of what you mean.

Whenever I've read into error writing and handling I inevitability get lost in the weeds. A tl;dr summary like you provided below would be a really helpful writeup in general, especially if it showed how it's just as easy as string errors and showed how much you get for free when doing things the right way.