cdap icon indicating copy to clipboard operation
cdap copied to clipboard

Introduce ErrorCodeProvider and use it in a few places.

Open janakigg opened this issue 3 years ago • 3 comments

janakigg avatar May 02 '22 12:05 janakigg

gitpod-io[bot] avatar May 02 '22 12:05 gitpod-io[bot]

The goal of ErrorCodeProvider is to provide 1) additional context on errors 2) make rules used for categorization more maintainable by providing the categorization (such as user vs system) in the code itself. But the problem is, whatever additional fields we put in ErrorCodeProvider will be seen in the logs and hence visible to the user. Logs are the only way this context can flow (since errors can happen while execution in Spark). Can the user see fields such as "error_type: system" in the logs?

Even if the categories are not directly added to ErrorCodeProvider, the rules should come down. For example, InvalidConfigurationException will always be a user error.

Note that, we now have three independent categories: error_type: user/system/unknown, plugin: true/false/unknown, dependency: true/false/unknown. We may add more categories as we see errors.

I expect that it will take a few PRs/iterations to get the right set of error groups and codes. Once we look at more exceptions, it should become more clear what error groups and codes we need to have to minimize the rules outside. I didn't want to modify too many places in the code where exceptions are thrown to keep the PR size small.

janakigg avatar Jul 15 '22 04:07 janakigg

I don't see how the information from these exceptions will be collected. Is that going to be in a different PR? Or are they parsed from the message or something like that?

How will somebody decide to categorize one of these exceptions as a user or system exception? Won't they look at the exception, look at what the code is doing, and then make a decision? In other words, shouldn't the code that is handling these exception already know what is a user vs system error?

I can see having some categorization for exceptions that are not explicitly caught and handled by the code, as they are exceptions that the code does not expect or know how to handle. But if we're already checking for very specific error conditions and attaching error codes to them, it seems like we should already know what type of error it is.

albertshau avatar Aug 01 '22 21:08 albertshau