New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mz/error handling #355
base: main
Are you sure you want to change the base?
Mz/error handling #355
Conversation
} | ||
)) as ApexTestRunResult; | ||
let testRunSummaryResults; | ||
try { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mingxuanzhangsfdx a couple of issues I see with the strategy of adding try catch on queries.
First, assuming all errors thrown by the query are due to out of memory exception will present the user will a false cause. Maybe the user's network fails some how causing a network exception or some other unexpected issue.
Second, out of memory errors cannot be handled by any means.
Please research approaches to dealing with out of heap space errors and then we can talk about what can be done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree with Pete. A not so very good approach is to look for specific message in the returned error message but it is ver brittle and can break if the underlying error message returned changes
@@ -153,7 +179,7 @@ export class CodeCoverage { | |||
} | |||
|
|||
@elapsedTime() | |||
private async queryPerClassCodeCov( | |||
public async queryPerClassCodeCov( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What change to public?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because the function is stubbed here in the unit test in order to mock the exception.
What does this PR do?
So far there is no error catching in the workflow of test reporting, users will run into an unclear failure such as "Range error: Invalid string length". We want to make sense of the frequency of the error and how many users have run into the error. We need to add error catching to report the failures so we could better decide our next steps for the issue.
What issues does this PR fix or reference?
@W-15226968@
Functionality Before
Users receive unclear error messages like "Range error: Invalid string length" when
stringify
failsFunctionality After
Users receive specific and clear error messages with advice so it is easy to understand and we are able to catch the errors in each bottleneck to make sense of the frequency of the bottlenecks.