Skip to content

Conversation

jasonmalinowski
Copy link
Member

@jasonmalinowski jasonmalinowski commented Jan 27, 2022

Commit-by-commit recommended. For the addition of severities, they were chosen based on the rough criteria described for each option:

/// <summary>
/// The severity of the error, see the enum members for a description of when to use each. This is metadata that's included
/// in a non-fatal fault report, which we can take advantage of on the backend to automatically triage bugs. For example,
/// a critical severity issue we can open with a lower bug count compared to a low priority one.
/// </summary>
internal enum ErrorSeverity
{
/// <summary>
/// Something failed, but the user is unlikely to notice. Especially useful for background things that we can silently recover
/// from, like bugs in caching systems.
/// </summary>
Diagnostic,
/// <summary>
/// Something failed, and the user might notice, but they're still likely able to carry on. For example, if the user
/// asked for some information from the IDE (find references, completion, etc.) and we were able to give partial results.
/// </summary>
General,
/// <summary>
/// Something failed, and the user likely noticed. For example, the user pressed a button to do an action, and
/// we threw an exception so we completely failed to do that in an unrecoverable way. This may also be used
/// for back-end systems where a failure is going to result in a highly broken experience, for example if parsing a file
/// catastrophically failed.
/// </summary>
Critical
}

@ghost ghost added the Area-IDE label Jan 27, 2022
@jasonmalinowski jasonmalinowski self-assigned this Jan 27, 2022
@jasonmalinowski jasonmalinowski force-pushed the more-fault-handling-cleanup branch 2 times, most recently from a958bba to 8197c61 Compare January 28, 2022 20:48
@jasonmalinowski jasonmalinowski force-pushed the more-fault-handling-cleanup branch from 8197c61 to 275c552 Compare February 3, 2022 19:24
@jasonmalinowski jasonmalinowski marked this pull request as ready for review February 3, 2022 22:08
@jasonmalinowski jasonmalinowski requested review from a team as code owners February 3, 2022 22:08
@jasonmalinowski jasonmalinowski requested a review from a team February 3, 2022 22:08
/// <returns><see langword="false"/> to avoid catching the exception.</returns>
[DebuggerHidden]
public static bool ReportAndPropagateUnlessCanceled(Exception exception, CancellationToken contextCancellationToken, ErrorSeverity severity)
public static bool ReportAndPropagateUnlessCanceled(Exception exception, ErrorSeverity severity, CancellationToken contextCancellationToken)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did 'Change Signature' make this easy?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It did! Although sometimes it did nothing at all, and my effort to debug that kept resulting in the debugger breaking. 😄

@jasonmalinowski

This comment was marked as outdated.

@jasonmalinowski jasonmalinowski force-pushed the more-fault-handling-cleanup branch from e609476 to 5827aea Compare February 7, 2022 20:39
Everything has to be categorized from now on.
Otherwise these are using the "regular" error reporting which will
send non-fatal events.
@jasonmalinowski jasonmalinowski force-pushed the more-fault-handling-cleanup branch from 5827aea to 0b5e47b Compare February 8, 2022 21:15
@jasonmalinowski jasonmalinowski marked this pull request as ready for review February 8, 2022 23:20
@RikkiGibson
Copy link
Member

Could you please elaborate on how severities were chosen in general?

@jasonmalinowski
Copy link
Member Author

@RikkiGibson Oh, forgot to update the PR for that. PR description updated now.

Visit(m);
}
catch (Exception e) when (FatalError.ReportAndPropagateUnlessCanceled(e))
catch (Exception e) when (FatalError.ReportAndPropagateUnlessCanceled(e, ErrorSeverity.General))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ErrorSeverity.General should be the default. This coding pattern is unnecessarily burdensome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants