Skip to content
This repository has been archived by the owner on Aug 29, 2023. It is now read-only.

Improve error messages and handling #393

Closed
3 tasks done
forman opened this issue Sep 22, 2017 · 4 comments
Closed
3 tasks done

Improve error messages and handling #393

forman opened this issue Sep 22, 2017 · 4 comments

Comments

@forman
Copy link
Member

forman commented Sep 22, 2017

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

  • user errors that originate from illegal, usually accidental user inputs (sometimes abuse of the software)
  • external errors that are usually out of direct control of users and developers, e.g. network errors, connection timeouts, I/O errors, OS errors, memory errors.
  • developer errors that occur because we developers don't comply with our own API contracts, e.g. pass None where it was not allowed to, assertions that were not met, etc
  • other errors errors not falling into one of the above categories, e.g. originating from (possibly buggy code) 3rd party libraries, errors of unknown source, Python internal errors

User 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:

  • Let all operations check inputs and raise ValidationError before passing values further down to xarray, numpy, etc.
  • Check all workspace code, turn WorkspaceError candidates into ValidationError. Consider removing WorkspaceError entirely as it is not helpful regarding the above error categories.
  • Check all data source code, turn DataAccessError candidates into ValidationError. Consider removing DataAccessError 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

@forman
Copy link
Member Author

forman commented Sep 22, 2017

The following errors are currently defined and raised in Cate:

  • cate.core.workspace.WorkspaceError
  • cate.util.web.webapi.WebAPIServiceError
  • cate.util.monitor.Cancellation
  • cate.util.cli.CommandError

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
@forman forman removed this from the IRM7 milestone Mar 15, 2018
@forman forman self-assigned this Mar 21, 2018
@JanisGailis
Copy link
Member

@forman ValidationError looks good. When you merge it to master, I can go over all ops to make sure it is used instead of ValueError when we do input validation.

@forman
Copy link
Member Author

forman commented Apr 16, 2018

@JanisGailis just finalised the GUI part, what's the status in ops?

Please also see #593

forman added a commit to CCI-Tools/cate-desktop that referenced this issue Apr 16, 2018
@forman forman assigned JanisGailis and unassigned forman Apr 16, 2018
@forman forman added the ops label Apr 16, 2018
@forman forman self-assigned this Apr 16, 2018
@forman forman added the ws label Apr 16, 2018
@JanisGailis
Copy link
Member

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.
Projects
None yet
Development

No branches or pull requests

3 participants