Updated custom Event Hub exceptions #151
Conversation
…rown in a wide variety of circumstances'.
|
|
||
| public static void SetConnectorOperation(string connectorOperation) | ||
| public static string ConnectorOperation |
There was a problem hiding this comment.
nit: Just curious - any reason to change to property?
Personally speaking, its not intuitive that properties are one time set so its easy to mistake this as an updateable one until we hit a runtime exception. But that's just my thinking.
Or maybe consider adding a comment indicating this is a one time set property so that it shows in intellisense, etc.
There was a problem hiding this comment.
In commit 65a6c34, since I needed a get accessor for the operation to specify the operation as Normalization/FhirTransformation, I thought I'd convert SetConnectorOperation to a set accessor to pair the accessors up under one ConnectorOperation property.
I reverted commit 65a6c34 in commit 2a6520f (see other comment), so this change got reverted, but I'll keep your point in mind in the future, thanks!
| : base( | ||
| message, | ||
| innerException, | ||
| name: $"{_errorType}{errorName}", | ||
| operation: ConnectorOperation.Setup) |
There was a problem hiding this comment.
I actually preferred these exceptions being categorized as Setup as opposed to Normalization/FhirTransformation to differentiate from actual operation issues post setup. Just curious on why we want to change this?
Adding @wi-y to add any thoughts as some of the earlier related metrics were also intentionally set with Setup.
There was a problem hiding this comment.
I remember we had discussed categorizing the Operation as Normalization/FhirTransformation to identify which Event Hub is the improperly configured one, but maybe I misunderstood which scenario to specify the Operation.
I checked with @wi-y offline, and keeping the Operation as Setup is more preferable and consistent with how we've been classifying Operation in the error metrics so far. Also, as you pointed out, the pod name can already help identify the Event Hub.
Therefore I reverted this change in commit 2a6520f.
…n exceptions." This reverts commit 65a6c34.
…bility) and to validate additional metric dimensions.
Updated custom Event Hub configuration exceptions:
InvalidOperationException's exception message when processing Event Hub exceptions, sinceInvalidOperationException'can be thrown in a wide variety of circumstances' (unfortunatelyInvalidOperationExceptioncurrently does not have a property such as error code that can be checked instead)