Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Document AnalysisError #127

Merged
merged 6 commits into from
Jan 21, 2025
Merged

Document AnalysisError #127

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
7463f0f
Document AnalysisError
dsavchenko Jan 9, 2025
16341b0
Update content/docs/guide-development.md
dsavchenko Jan 9, 2025
36735fb
Update content/docs/guide-development.md
dsavchenko Jan 9, 2025
7887586
Update content/docs/guide-development.md
dsavchenko Jan 9, 2025
4408afc
update screenshot
dsavchenko Jan 10, 2025
3c8e2dc
leftover words
dsavchenko Jan 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Binary file added content/docs/analysiserror.png
View file
Open in desktop
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
8 changes: 5 additions & 3 deletions content/docs/guide-development.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -230,11 +230,13 @@ the same result every time but still be reproducible (see motivation on [the dif

### Handling exceptions

It can happen that your analysis workflow is expected to produce no data products in some cases, for example, if there is no data for a specified source and time interval, if the parameters specified by the user have wrong format, or in other "exceptions" In this case, it would be good to inform the user what happened. This can be done using the raise `RuntimeError()` method directly in the notebook, as shown below:
It can happen that your analysis workflow is expected to produce no data products in some cases, for example, if there is no data for a specified source and time interval, if the parameters specified by the user have a wrong format, or in other exceptional cases. Because of that, it would be good to inform the user of what happened. This can be done by defining a special class for the purpose (eg `AnalysisError`), directly in the notebook, and this designates the "expected" exception. An example of definition and usage is shown below:

![image](tmp21.png)
![image](analysiserror.png)

Don't worry if you do not succeed to foresee all possible exceptions at the initial development stage. If unforeseen exceptions would occur when the service is already deployed and available to users, each time an unforeseen exception occurs, you will be notified and invited to patch your notebook to handle this exception (perhaps raising a new `RuntimeError()` case in the appropriate cell).
Any exception raised during the worfklow execution will propagate and shown by the MMODA platform.

Don't worry if you do not succeed to foresee all possible exceptions at the initial development stage. If unforeseen exceptions would occur when the service is already deployed and available to users, each time an unforeseen exception occurs, you will be notified and invited to patch your notebook to handle this exception (perhaps raising a new `AnalysisError()` case in the appropriate cell).

### Using renku secret storage

Expand Down
Loading