Closed orichters closed 1 month ago
It is a bit hit and miss. Somebody would have to convert the ~500 usages of that idiom in the package,. Then users would have to stick to it. But the ~450 other uses of mbind()
would not benefit.
The solution is obvious: proper error reporting by mbind()
itself, instead of a cooked-up wrapper function.
What Michaja said. Have you tried creating a PR to magclass?
No, my only experience with "magclass" is: "replacing all occurrences by quitte".
https://github.com/pik-piam/magclass/blob/master/R/mbind.R#L79-L81
I guess we could make these error messages more meaningful?
https://github.com/pik-piam/magclass/blob/master/R/mbind.R#L79-L81
I guess we could make these error messages more meaningful?
The problem is: to return really meaningful error messages, one needs to make some assumptions about the use mbind()
is put to. Which might or might not jive with Jan.
Specifically, one hast to assume that few regions/years/names are bound to many regions/years/names, that the latter are the first inputs
element, and that only the differences to the first inputs
element are significant.
I have a draft, I just need to polish it a bit before submitting it to the court of RSE opinion.
Dear colleagues, I find it sometimes really annoying and difficult to find out where and why a remind2 function call fails exactly, because mostly somewhere a
mbind
files. Often, the report functions have the following structure:Now, if I do some stupid stuff, I get this in the logs:
And often, also
rlang::last_trace()
is not really helpful, in particular, if the var name was not typed in as here but rather composed of some sets.I thought we could maybe replace it by something like that which would give a much more consistent and meaningful error message:
And then use:
Now I see directly which variable was affected and what was the issue (
all_regi
differs).Maybe you have even better ideas, @0UmfHxcvx5J7JoaOhFSs5mncnisTJJ6q, @Renato-Rodrigues, @fbenke-pik.