zowe-explorer-vscode: Centralized error handling

It would be nice to have a new function that handles error messages.

For Example:

If (err.errorCode === 401) {
    await ErrorHandling("ZWEEX401E")
}

public async ErrorHandling(errCode) {
    switch(errCode) {
        case "ZWEEX401E": {
             vscode.window.showErrorMessage(localize("getChildren.error.response", "Invalid 
             Credentials for profile") + `\n${this.label}\n` + ". Please make sure that the 
             credentials are valid.");

And then we could have a document like the api-layer troubleshooting for easier troubleshooting.

About this issue

Original URL
State: closed
Created 5 years ago
Reactions: 3
Comments: 17 (17 by maintainers)

Most upvoted comments

@jellypuno @zFernand0 Hey, so I’m doing some research, and suggested for smaller TS projects is to throw exceptions, not to use error codes. With error codes, we’d have to keep the documentation & handling function up-to-date for the error codes all the time.

Also another thought, maybe we shouldn’t be throwing exceptions at all? Instead we could return some special data type, so that we’re locked into best practices by using this type. I like this approach for instance: https://benjaminjohnson.me/blog/typesafe-errors-in-typescript

Basically, we’d make a new data type that looks like this:

type ResultSuccess<T> = { type: 'success'; value: T }
type ResultError = { type: 'error'; error: Error }
type Result<T> = ResultSuccess | ResultError

And we’d return this data type from our functions…especially from all the API functions. It would be nice to use it everywhere in ZE though.

If we use this, extenders (and us) can’t ignore errors that are returned. We can’t accidentally miss catching an error and thus crashing the app.

katelynienaber on May 7, 2021

This will definitely be helpful if the decision is to move forward with Message IDs. If someone has any concerns about this, please feel free to bring it up.

This centralized location could also be used for handling any error mapping as well (if we decide to go that route too).

My only concerns are:

The extra maintenance (which probably isn’t too bad if we had scripts that produced said troubleshooting document for example)
The temporary inconsistency (at least until we go back and create Message IDs for every other error message that we create, which could be a bit harder to automate)

zFernand0 on Dec 10, 2019