You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As part of #23795, we've found that errors handled by the web infrastructure are inconsistently tagged by our metrics support: an "exception" tag is added too broadly, and only in some cases.
Since #23795 will remove that behavior by default, we'd like to provide a way for developers to still get that behavior on an opt-in basis.
We should provide a request attribute for both MVC and WebFlux that developers can use and set to the exception being handled by the application code. Right now we have a similar (yet private) mechanism in both implementations of DefaultErrorAttributes that stores the exception as early as possible in an attribute.
Developers could then opt-in and store the exception if they wish to:
As part of #23795, we've found that errors handled by the web infrastructure are inconsistently tagged by our metrics support: an
"exception"
tag is added too broadly, and only in some cases.Since #23795 will remove that behavior by default, we'd like to provide a way for developers to still get that behavior on an opt-in basis.
We should provide a request attribute for both MVC and WebFlux that developers can use and set to the exception being handled by the application code. Right now we have a similar (yet private) mechanism in both implementations of
DefaultErrorAttributes
that stores the exception as early as possible in an attribute.Developers could then opt-in and store the exception if they wish to:
In this case, the metrics infrastructure would add the
"exception"
tag to the recorded metric.The text was updated successfully, but these errors were encountered: