4 ms·

Some factors for this - When prototyping, deferring worrying about exact error types is helpful - In applications, you aggregate so many types of errors, some

• monocasa 7y ago
  For sure. 1 - Just have a Todo(String) in your error enum while prototyping. Remove it as you clean up a prototype, and you get a nice set of compiler errors telling you everywhere that needs to change. 2 - If you're aggregating so many error types that it's unwieldy, you're probably doing to much in one place. That has all sorts of down stream issues with testability and what not. Hacking your error types to make it easier is probably not the best option.
  • epage 7y ago
    > 2 - If you're aggregating so many error types that it's unwieldy, you're probably doing to much in one place. That has all sorts of down stream issues with testability and what not. Hacking your error types to make it easier is probably not the best option. I'd disagree. In a static-site-generator, I need to deal with - file format errors - syntax highlighting errors - io errors - Template language errors - Adhoc errors I construct throughout the application - Regex errors - RSS errors - jsonfeed errors - sitemap errors - git errors Without even getting into any errors from the webserver that is being run. Yes, I could carefully construct an error enum for each subsection of the application and bubble those up ... but why? I'm not programmatically acting on these but sending them up to the user.
    • monocasa 7y ago
      By dumping all those together, you've lost context as to why or where these errors have come from. Just yolo displaying io errors is a terrible experience for your users.