> 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 te

> 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.