This repository has been archived by the owner on Aug 29, 2023. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 15
Improve error messages and handling #393
Labels
Comments
The following errors are currently defined and raised in Cate:
|
kbernat
pushed a commit
that referenced
this issue
Sep 25, 2017
kbernat
pushed a commit
that referenced
this issue
Sep 26, 2017
kbernat
pushed a commit
that referenced
this issue
Oct 2, 2017
kbernat
pushed a commit
that referenced
this issue
Oct 2, 2017
kbernat
pushed a commit
that referenced
this issue
Oct 2, 2017
kbernat
pushed a commit
that referenced
this issue
Oct 2, 2017
kbernat
pushed a commit
that referenced
this issue
Oct 2, 2017
kbernat
pushed a commit
that referenced
this issue
Oct 2, 2017
kbernat
pushed a commit
that referenced
this issue
Oct 3, 2017
This was referenced Mar 26, 2018
forman
added a commit
that referenced
this issue
Mar 28, 2018
@forman |
@JanisGailis just finalised the GUI part, what's the status in Please also see #593 |
I should be able to go over this and finish it tomorrow. Are the relevant changes on master already, or still on a feature branch? |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Expected behavior
Cate's error messages should clearly indicate the type of error occurred, and if possible, guide the user towards a solution of a problem.
Examples for the types of error to be distinguished are
None
where it was not allowed to, assertions that were not met, etcUser errors and external errors should be displayed without alarming stack traces. Messages should be concise, clear, understandable, and not incriminate the user. It shouldn't contain exclamation marks and avoid words in capital letters.
Developer errors and all other errors should always include the option to display the full trace back of the call stack into the code.
EDIT:
ValidationError
before passing values further down to xarray, numpy, etc.WorkspaceError
candidates intoValidationError
. Consider removingWorkspaceError
entirely as it is not helpful regarding the above error categories.DataAccessError
candidates intoValidationError
. Consider removingDataAccessError
entirely and replacing it by std Python error types.Actual behavior
We currently lack a sophisticated error handling in the user interface. We don't distinguish error types, so any error occurring in
cate-core
is signaled to users in the same way: a message box with a (usually too long) trace back - which is kind of scary and annoying, especially if it is a question of harmless problems.Specifications
Cate 0.9.0.dev7
The text was updated successfully, but these errors were encountered: