Skip to content

Conversation

@stopping
Copy link

@stopping stopping commented May 5, 2015

No description provided.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not a fan of needing "throws" declarations---they end up being awkward to use due to language requirements. I think your implementation re-throwing it a couple levels and then ending up with a printStackTrace and a TODO is evidence of it being an "anti-pattern". Unfortunately, ParseException is an Exception and not a RuntimeException, so the language leaves you no choice (again, "anti-pattern").

How do you feel about just throwing it as a RuntimeException (to avoid the language shenanigans)? Then later, for proper handling, we can install a few high-level exception handlers: e.g. an Exception caught while doing downloading/parsing of all the pages could gracefully retry (for something like a network failure) or forcefully exit (for a deterministic parsing failure), while a frontend failure while serving the site should be logged but not bring down the server.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants