[Proof of Concept] Azure Monitor - Refactoring the EventSource#14781
[Proof of Concept] Azure Monitor - Refactoring the EventSource#14781TimothyMothra wants to merge 7 commits intomasterfrom
Conversation
|
@xiang17 need your input when this PR is ready for review |
sdk/monitor/OpenTelemetry.Exporter.AzureMonitor/src/AzureMonitorTraceExporter.cs
Outdated
Show resolved
Hide resolved
| { | ||
| AzureMonitorTraceExporterEventSource.Log.ConnectionStringError(ex); | ||
| throw new InvalidOperationException("Connection String Error: " + ex.Message, ex); | ||
| var newEx = new InvalidOperationException("Connection String Error: " + ex.Message, ex); |
There was a problem hiding this comment.
Curious - is this ex.Message localized or not (or not decided at this moment)?
There was a problem hiding this comment.
I honestly don't know if the ex.Message is ever localized. In theory, exceptions could be thrown from any dependency library so we would have to ask did every library owner localize their messages.
At the moment we're not localizing our own messages.
|
Hi @TimothyMothra. There hasn't been recent engagement on this PR. Would you please be so kind as to let us know if this is still an active work stream or if the PR should be closed out? |
|
Since there hasn't been recent engagement, I'm going to close this out. Please feel free to reopen if you'd like to continue working on these changes. |
Creating this PoC to get feedback on this approach.
The idea behind this change is to have basic Events in the EventSource class to prevent each PR from creating new Event methods.
This should simplify and standardize the way to handle exceptions.
Changes
Comment
An earlier version of this was re-throwing the exceptions from the EventSource class, to fully encapsulate the exception handling.
I had this working, but it required extra considerations to preserve the stack trace.
I decided against this approach because it wasn't obvious to myself (and FxCop) that a
try/catchblock would re-throw any exception.