Raising BlueprinterError on some situations

[wollistik]

• Raising errors on invalid included views
• ReRaising error with details on extraction error

[mcclayton]

This is valuable feedback @wollistik, and we appreciate the PR! The core maintainers will take a look at this PR soon and provide feedback in carrying that through. Thanks!

[lessthanjacob]

Hey @wollistik! Apologies for the delay here.

Looking at the proposed changes, I do appreciate the additional of more intentional error handling! However, I'd actually advocate more towards implementing error classes that describe the error via their type, as opposed to needing to introspect the included message of a generic error class.

We should be able to get the best of both worlds here by simply subclassing each error class from BlueprinterError: Users can explicitly handle a Blueprinter::FieldExtractionError, or they could rescue BlueprinterError generally.

[wollistik]

Hi @lessthanjacob ,

a lot of time has passed since the initial PR :wink: I now also prefer designated error classes and adapted the code and the test cases accordingly. I took a sample from the DateFormatter class and put the error class definitions where they are used. But if you prefer them to be all at one file (e.g. directly side by side with BluprinterError), I can adjust my PR.

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[jmeridth]

Not stale /cc @njbbaer

[github-actions[bot]]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.