NEWS for dreamerr

Version 1.2.2

Bug fixes

User visible changes

Version 1.2.1 (31-08-2020)

Bug fixes

User visible changes

Version 1.2.0 (08-06-2020)

Important changes (no retro compatibility)

test = function(x){
  check_arg(x, "numeric vector")
}
# Before (version <= 1.1.0)
test(c(5, NA)) # => Error
# Now (version >= 1.2.0)
test(c(5, NA)) # => is OK
test = function(x){
    check_arg(x, "logical scalar")
}
# Before (version <= 1.1.0)
test(0) # => is OK
# Now (version >= 1.2.0)
test(0) # => Error, must be logical

The new behavior is equivalent to the previous behavior when the type was strict logical. Now strict logical has been removed and loose logical has been introduced which accepts 0 and 1. Why this change? I remarked that when you allow arguments of very different types, one of which was a logical scalar, it was really useful to distinguish between them safely using isTRUE or is.logical. With the previous default behavior you could have a 0 or 1 that would prevent you from doing that. Of course you could use strict logical to trigger that behavior but it was non-intuitive.

New features

x = "t"
y = check_value_plus(x, "match(This, Is, Raw)")
y # => "This"
fml = ~head(Petal.Length)
z = check_value_plus(fml[[2]], "evalset numeric vector", .data = iris)
z

Other changes

Bug correction

Version 1.1.0 (2020-05-03)

New functions

New features

User visible changes

Change in argument names

Bug correction

First version: 1.0.0 (2020-04-12)

This package is the outcome of over a decade of coding and developing packages in R. As a package developer I always wanted my code to be “safe”: so that if a user provides arguments of the good type the functions always work, and if there’s an argument of the wrong type then an informative error message is shown.

The big problem is that error handling is extremely time consuming, especially if you want to specify informative error messages stating clearly where the problem comes from. This problem is compounded when you want to offer the user flexible arguments that can be of many types. To do error handling properly in such situations is a nightmare: you end up with big if/else trees with a lot of different messages. And it doesn’t improve the speed of your code! So you have little incentives to invest time in proper error handling.

This is why I developed this function. It’s one line of code, and it does all the work for you. From the developer side it’s super simple, and from the user side, s/he ends up with extremely informative error messages therefore saving a lot of time in debugging.