Feature Request: conditions should be classed

[iqis]

Feature Idea

If the function signals a condition I want to know its class, so I can tell it apart from other conditions, and selectively handle them from a higher level.

Relevant Input

N/A

Relevant Output

N/A

Reproducible Example/Pseudo Code

e.g.

warn_if_something_bad() should throw a condition that has classes warning, admiral.warning and admiral.warning.something_bad.

I want to be able to do:

withCallingHandlers({
    doing_a_task() 
}, 
`admiral.warning.something_bad` = \(w){
    log_this(w)
}
`admiral.warning.something_else_bad` = \(w){
    # ignore... try restart... etc.
})

[thomas-neitmann]

Great suggestion @iqis! This will definitely improve the package. Would you be interested in contributing to {admiral} by implementing this yourself?

[thomas-neitmann]

This would be a great enhamcement @sadchla-codes @zdz2101.

[bms63]

• Should be worked on simultaneously with Feature Request: conditions should be classed admiraldev#243
• First step is identifying the functions that need to be updated

[bms63]

Linking closed issue from admiraldev pharmaverse/admiraldev#243

[manciniedoardo]

Closing this discussion due to low appetite for implementing it.

[bundfussr]

I think there was appetite but no time for implementing it. With this implemented it would be easier to provide helpful error messages to users because if a function calls another function which issues an error, the outer function can catch the error from the inner one and create a message which refers to the arguments specified for the outer function (instead of internal objects of the function). We could also remove the duplicate_msg argument from derive_vars_merged(). This was introduced to work-around this issue.
I would suggest implementing it after the 1.0.0 release.

[bms63]

Let's keep this discussion open as i also feel this is an important topic.

[manciniedoardo]

Closing due to lack of activity.