Improve user feedback for errors during plot compilation #3203
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Because most
so.Plot
methods simply define a spec and defer operations until the time when the plot is compiled, errors caused by bad user inputs (or seaborn edge cases) that cannot be trivially detected may not arise until later and will not be clearly connected to the problem.In general I'd like to try and be as helpful as possible with what we actually raise to avoid this becoming a pain point for the new interface. This PR represents the first step, defining a
PlotSpecError
exception class that gets raised in an exception chain to provide some additional context that may help diagnose issues. Right now the use is limited to scale setup and scaling operations and the main benefit is that the exception message can call out the plot variable that was being processed when an exception was raised.e.g., the traceback for the operation in #3106 (which is being obviated anyway by #3190, but is a useful demonstration):