Closed Deleetdk closed 6 years ago
This seems to work for debugging(see link), but I think it would be nice to either have debug_pipe either use this operator for debugging(find and replace %>% with ->.;) so you can easily step through the sequence, or some other method to easily step through pipe sequences. http://www.win-vector.com/blog/2016/12/magrittrs-doppelganger/
I would rather figure out how to get browser()
working; I think that's possible now - see #172 for progress.
Pipes are great, but debugging pipes is difficult.
Often I have a pipeline like this:
It is not always be easy to figure out where the error happens.
The base-r try approach is fairly verbose:
But it gets you what you need to find the error: the
browser
call in the environment where the first pipe is called from.I wonder if one can make a pipe approach. First attempt:
Does not work because the error does not get forwarded down the pipe to the error catcher.
So the error catching must happen earlier in the pipeline. I can think of two approaches::
%E>%
,E
for error, analogous to%T>%
try_pipe()
.The first would be less verbose, so presumably preferable. It would do something like the following:
I tried unsuccessfully to implement it. Here's my broken code. It fails due to the missing argument in the call to
rhs
.So for now I'm stuck to using something like this:
With that one can write code like this:
And
browser
is correctly called from withinsome_func2
so one has the necessary context to figure out the problem.The debug pipe would have to be special. It must not only pass
lhs
torhs
, but evaluate all following pipes. Otherwise, it would only catch an error in the immediately following pipe and not 5 steps further down. So, like%<>%
, it would always have to make sure it is the first pipe in the pipeline. Since%<>%
can do this, it seems possible that one could make a debug pipe too.Am I missing something obvious here?