Chained errors with contextual info in layers

[thomasp85]

This PR improves the error reporting when errors occur during evaluations of a layer. It also adds an improvement to all errors in ggproto methods since the methods are now called by name so we avoid the useless Error in f() we get now.

The new look of layer errors is:

ggplot(economics_long, aes(date, value01, colour = date)) +
  geom_point() + 
  geom_line(linetype = 2)
#> Error in `geom_line(linetype = 2)`:
#> ! Problem converting geom to grob
#> ℹ Error occurred in the 2nd layer
#> Caused by error in `draw_panel()` at ggplot2/R/ggproto.r:179:18:
#> ! `geom_line()` can't have varying colour, size, and/or alpha along the line when
#>   linetype isn't solid

which is a mouthful but a huge improvement in terms of letting the user understand how their code is wrong

The remaining question is if this error chaining should be expanded to other ggproto objects in play during plot rendering. I feel it is less imperative than the layer errors because facets and coords are singular in the plot and they are thus less likely to cause confusion as to where the error occurred. I'm however open to expanding the try_fetch implementations in ggplot_build() to cover it all

[hadley]

This is awesome 😄

[lionel-]

Looks great!

I notice in these examples that we are missing full stops in error messages, which are recommended by our style guide. Should we take this opportunity to ensure full stops in the messages?

Also in dplyr chained errors follow this phrasing:

! Problem while computing `stop("bar")`.

So maybe this:

! Problem converting geom to grob

Should be:

! Problem while converting geom to grob.

[clauswilke]

This is great!

One minor comment: There is a bit of a naming inconsistency between "stat" and "statistic", sometimes you use one, sometimes the other. I think "stat" is used much more widely and so I would consider using it always.

There are two cases where you currently write out "statistic", I believe:

• "computing statistics"
• "mapping statistics to aesthetics"

I think it would be fine to write instead:

• "computing stats"
• "mapping stats to aesthetics"

(Don't feel strongly about this either way.)