To error_chain! or not to error_chain!: ergonomic macros

I just used the error-chain crate for the first time. I refactored a small library crate I made for parsing a custom file format. Before I had a simple enum I used as the error type with Debug, Display, and Error traits implemented. The error handling was clear and concise, and there were only a few variants for the enum. It was very straightforward; I think the error_chain! version is less so.

It occurred to me that the error_chain!{...} macro is kind of a DSL within rust. There was more of a learning curve than I expected because the content of the macro didn't follow the basic syntax rules as the rest of the language, especially when it comes to the use of commas, semi-colons, parenthesis, and braces.

The format!(...) and print!(...) macros don't seem to have that problem with the notable exception that they allow a variable number of arguments.

It seems there is a lot of potential here to create sub-languages that apparently follow different syntax rules than basic rust. The nom crate is another example.

This causes a big learning curve and seems very un-ergonomic. Especially in the case of nom, you basically have to learn a new language.

Is this practice recommended by the rust team or the community? Are their style guidelines for macros that encourage more print!(...) like macros or encourage more DSL like macros?

4 Likes

The nom crate follows a different syntax rules because it is very similar to regular expression which in itself a different language on its own.