Stackdriver Error Reporting should display the contents of Exception.Data.

[SurferJeffAtGoogle]

Describe the solution you'd like
A clear and concise description of what you want to happen.

.NET exceptions have a Data dictionary, where I can add any tags I want. For example:

            // Generate an error that Stackdriver should capture
            try {
                // [START error_reporting_setup_dotnetcore_force_error_controller]
                throw new Exception("Generic exception for testing Stackdriver Error Reporting");
                // [END error_reporting_setup_dotnetcore_force_error_controller]                
            } catch (Exception e) {
                e.Data.Add("flavor", "raspberry");
                throw;
            }

However, the Data dictionary is not visible in stackdriver error reporting:

It would be useful to display the dictionary in Error Reporting, so I can effectively annotate exceptions.

[amanda-tarafa]

I think this is doable, I'll take a look.

[amanda-tarafa]

Hi @SurferJeffAtGoogle, in a few minutes I'll submit a PR that addresses this FR. Just wanted to add a few clarification notes.

The ErrorEvent resource does not define a property in which to include extra information similar to System.Exception.Data so you will never see this information on the Error Reporting section of the Cloud Console. This does not depend on us on the client side but on the API definition and the UI design.
Luckily, an ErrorEvent is a partial view of a LogEntry which defines a property labels more suited to store the data in System.Exception.Data in a more structured way that can be used for filtering etc.. So to see this information (once the PR is submitted and released) you can click on the View Logs link on the Error Reporting UI as shown below:

You then will se something like this:

[SurferJeffAtGoogle]

Original note that inspired this feature request:
https://medium.com/@mikedube_/excellent-article-have-you-found-a-way-to-annote-error-trace-679727ec10fc

[amanda-tarafa]

What we are wondering about now is where exactly and in what format to store the Exception.Data in a LogEntry. Here are some of the options we are considering:

1. Store each entry of Exception.Data as an entry in LogEntry.Labels (which is a dictionary as well). LogEntry.Labels are intended for storing key-value pairs of user defined information. They can be used in filters and are expanded into columns when stored, so potentially can appear as columns in reports. If Exceptions has huge amounts of info in Exception.Data, both in terms of number of entries and size, then this could a problem though.
2. Store each entry of Exception.Data as a property in LogEntry.JsonPayload. JsonPayload is intended to store more general information, but, as Labels, can be used in filters and properties will be expanded in columns.

• There's no practical difference between the two options above, just the slightly subjective description of Labels being intended to store key-value pairs and JsonPayload being intended to store more general information in a JSON format (which can always be regarded as a set of key-value pairs anyway).

3. Construct a "squashed" string with all the information in Exception.Data and add it to one of the string properties in LogEntry, like Message. The advantage of this is that the Message field will be stored as is (no column expansion) and can also be used in filters although not in as a precise a manner as Labels or JsonPayload could be used.
4. Construct the same "squashed" string but add is one Label (Exception.Data => squashedString) or as one property in JsonPayload. Filtering wouldn't be as precise as when adding each entry individually but you wouldn't see a "random" set of columns in a possible report, etc.

[amanda-tarafa]

Blocked, waiting for original requester to give their opinion on the several options we have.

[amanda-tarafa]

Moving this issue to our backlog (#2822 ) given that the original requester hasn't confirmed what option better addresses their use case.
@SurferJeffAtGoogle we can reopen if the original requester gets back to us or if we get similar requests for this feature from other users.