Error code definition

[zhengjianhui]

I have some ideas about the error code for mpv or kuai, can we use something like the following to define it? I would like to see what people think.

Application ID (three-digit number) - Module ID (three-digit number) - Error Type (one-letter) - Error Code (five-digit number)

For example: 001-001-E-00001

The meaning of each category is as follows:

Application ID: Indicates which application the error belongs to and can be represented by a three-digit number. For example, 001 represents application MVP1, and 002 represents application MVP2.

Module ID: Indicates which functional module the error belongs to in the application, and can be represented by a three-digit number. For example, 001 represents the login module, and 002 represents the market module.

Error Type: Indicates which type of error the error belongs to and can be represented by a one-letter code. For example, P represents parameter errors, B represents business errors, and O represents other errors.

Error Code: Represents the specific error under the error type and can be represented by a five-digit number. For example, 00001 represents a signature error, and 00002 represents a cell not found error.

The benefit of using this error code is that it can quickly locate errors and display them in a friendly way.

Reference

[Keith-CY]

I have 2 questions about this design

1. Application ID, why should we define app id in the error, would it be too coupled. And there should be a independent monitor collecting errors from an application, would it be enough to differentiate errors from various applications?
2. Function ID and Error Type, Function ID and Error Type help us to locate the origin of an error, but error.stack has the same functionality, is it not enough in some cases?

[zhengjianhui]

1. Application ID, why should we define app id in the error, would it be too coupled. And there should be a independent monitor collecting errors from an application, would it be enough to differentiate errors from various applications?

For the first question, since there are cases of third-party directly calling the HTTP API in ForceBridge, I think it may be meaningful to use the application ID. As for maintaining an error list, I think it could be useful for improving error handling and debugging in the future.

As for the second question, I think the statement may have been incorrect. It would be more appropriate to use the module ID instead of the function. As for the function's error, I think it will be classified into an error code, and maintaining a list of error codes and descriptions could be helpful for developers to understand and handle errors more effectively.

[Keith-CY]

1. Application ID, why should we define app id in the error, would it be too coupled. And there should be a independent monitor collecting errors from an application, would it be enough to differentiate errors from various applications?

For the first question, since there are cases of third-party directly calling the HTTP API in ForceBridge, I think it may be meaningful to use the application ID. As for maintaining an error list, I think it could be useful for improving error handling and debugging in the future.

As for the second question, I think the statement may have been incorrect. It would be more appropriate to use the module ID instead of the function. As for the function's error, I think it will be classified into an error code, and maintaining a list of error codes and descriptions could be helpful for developers to understand and handle errors more effectively.

If the error code is coupled with applications, we should maintain a list of applications for users to check the error code, because searching the entire error code is the most intuitive action to figure out its meaning. Besides, we cannot order developers to use distinct application ids, so there could be 2 applications throwing a same error code with same app id.

For the second point, I'm not sure how much it helps, because error.stack delivers it already.

[zhengjianhui]

If the error code is coupled with applications, we should maintain a list of applications for users to check the error code, because searching the entire error code is the most intuitive action to figure out its meaning. Besides, we cannot order developers to use distinct application ids, so there could be 2 applications throwing a same error code with same app id.

For the second point, I'm not sure how much it helps, because error.stack delivers it already.

I agree with the second point, so going back to the first point, using error codes in MVP applications could be appropriate. However, since this is an MVP application, it might be sufficient to simply define a few error codes to begin with, which should make them easier to maintain.

[yanguoyu]

I also confusing with the Application ID, people don't need to register an Application when creating a DApp by kuai, so maybe all DApp application ID will be 001. If the Application symbol is needed, maybe setting it as a string is good, so it will be the DApp name.

[zhengjianhui]

I also confusing with the Application ID, people don't need to register an Application when creating a DApp by kuai, so maybe all DApp application ID will be 001. If the Application symbol is needed, maybe setting it as a string is good, so it will be the DApp name.

Developers may use kuai to build multiple applications and rely on these applications to continue building new ones, so there may be scenarios where Application ID are used. However, using the name of the Dapp is a good idea.

[Daryl-L]

I think we can provide a platform for developers to register their DApp, better record on chain. There are some advantages for developers to doing so.

If developers register their DApp, users and other developers could find their products more conveniently. To register to the platform, they could be more close to us, or to official, I think every developer is willing to do this.

Of course, it is not mandatory. Developers can choose to register or not.

[zhengjianhui]

I think we can provide a platform for developers to register their DApp, better record on chain. There are some advantages for developers to doing so.

If developers register their DApp, users and other developers could find their products more conveniently. To register to the platform, they could be more close to us, or to official, I think every developer is willing to do this.

Of course, it is not mandatory. Developers can choose to register or not.

Sure, you can add a usage instruction in the README.md file and list the projects or users who are using kuai

[Keith-CY]

Basic design tomorrow

[zhengjianhui]

Basic design tomorrow

The current idea is to provide a unified error style through KuaiError and errors_list, and move the error definition to the common module on the basis of the current implementation, which can be used by different modules. The benefits of doing so are that each module can maintain its own error definition while maintaining a consistent style, which is helpful for future document writing and error locating.

If there are no further issues, I will make the changes in this pr204.

[Keith-CY]

Basic design tomorrow

The current idea is to provide a unified error style through KuaiError and errors_list, and move the error definition to the common module on the basis of the current implementation, which can be used by different modules. The benefits of doing so are that each module can maintain its own error definition while maintaining a consistent style, which is helpful for future document writing and error locating.

If there are no further issues, I will make the changes in this pr204.

LGTM

[Keith-CY]

PR:

• add a kuai level global exception handling: https://github.com/ckb-js/kuai/pull/204
• make global exception handler flexible: https://github.com/ckb-js/kuai/pull/223