This vignettes demonstrates how to deal with learners which raise exceptions during train or predict.

Setup

First, we need a simple learning task and a learner which raises exceptions. For this purpose, mlr3 ships with the learner classif.debug:

The hyperparameters let us control (a) what conditions should be signaled (message, warning, error), and (b) during which stage (train or predict). Additionally, we can tell the learner to provoke a segfault which tears down the complete R session. With its default settings, it will do nothing special: it learns a random label and which is used to create constant predictions.

No error handling

In the defaults, mlr3 does not handle errors. Thus, the exception raised by the unittest learner stops the execution and can be tracebacked:

Encapsulation

During parallelization, error messages (as well as normal output or warnings) are often not properly forwarded to the master R session, or they arrive in a confusing order. The learner execution can be encapsulated, so its output is logged to the experiment instead of just printed to the console:

You can also enable the encapsulation for the predict step of an experiment by setting encapsulate_predict.

Another possibility to encapsulate is execution via package the callr. callr spawns a new R process, and thus guards us from segfaults. On the downside, starting new processes comes with a computational overhead.

Note that, although no exception has been raised with encapsulation, it is impossible to perform the predict step without a model:

As a workaround, we define a learner in the next section which is used as a surrogate to create predictions.