Downgrading errors to warnings so that our APIs don't break the user's workflow

[tuscland]

In reference to #173.

First we need to define the scope: Project API, or anything that can be used during computation (data cleaning, model training). Calling skore.load should behave as a conventional program (i.e. raise an exception on error) because it is at the very begining of a script, so there minimal damage if the exception occurs.

In addition, there should be a way to control this behavior. While only issuing warnings should be default, some users might also want a strict mode (raise an exception instead of issuing a warning). Therefore a global setting should be available to control how exceptions are handled.

Finally, we should be mindful that not raising an exception can make the control flow more complex. Are there specific programming patterns we should adopt to help with that and explicitely document as code our intentions? I suggest that we first indentify potential code spots where we do not want to raise an exception, and discuss here the code we should craft to address this question.

We would to manually check that using skore does not cause the user's workflow/script to break. This means that we want warnings instead of raising exceptions.

[tuscland]

We should have a look at how other projects deal with.

It seems Python offers solutions to control the behavior.

But it raises the question of the flow, e.g.:

• A put fails with a warning
• Later in the code, a get is performed on the same key, issuing a warning as well, retuning null
• The user's code could fail as well, but we have no way to help there.

---

Implementation idea from @rouk1: use a decorator to specify which functions benefit from this behavior.