The previous anomaly reporting PR created a separate mechanism to report certain kinds of logging errors. This PR expands that support to all the errors that the SDK can generate, and so creates a unified mechanism through which errors are logged and presented to partner developers.
The advantages here is that anomalies can now be tracked using the same extensive error handling that the other errors use. This includes console logging, analytics, and Xray.
Changes discussed below.
ErrorHandling
The previous AnomalyHandling directory was renamed to ErrorHandling and Errors.swift now lives in that directory.
The AnomalyType enum now lives inside MetricsLoggerError for consistency. This is where all other runtime errors in our package live. It made sense to make these anomalies into errors because the existing ClientConfigError type contains runtime and configuration error values. This design allows us to expose the handling in the previous PR to handle all kinds of errors.
New error enumerations and types were added alongside the anomalies that were moved over. This was for naming and value consistency. For example, we previously had only an error for invalidWireFormat; we now have errors for invalid values for all the enums in ClientConfig.
Console Logging
ErrorHandler now logs errors to console automatically, using OSLog at the error severity. This functionality obeys the value set by ClientConfig.osLogLevel. Separate classes don't need to console log their errors; this is now done in ErrorHandler.
As a result of this, we now create ErrorHandler even if metricsLoggingErrorHandling is .none, but osLogLevel is .error or higher.
Modal Dialog and Release Builds
We now guard the strings and the ErrorModalVC with #if DEBUG to exclude the code and resources in release builds. This adds the limitation that the dialog will only appear in debug builds, which limits their audience. Even so, it still makes sense to add this guard, because:
It's unlikely that the modal is useful outside of development, and
This prevents the dialog from accidentally showing up in production
This also means that setting ClientConfig.metricsLoggingErrorHandling to .modalDialog or higher in a release build is a no-op. It still makes sense to include the setting though, since it's exposed in ClientConfig, and hence to Remote Config as well.
The previous anomaly reporting PR created a separate mechanism to report certain kinds of logging errors. This PR expands that support to all the errors that the SDK can generate, and so creates a unified mechanism through which errors are logged and presented to partner developers.
The advantages here is that anomalies can now be tracked using the same extensive error handling that the other errors use. This includes console logging, analytics, and Xray.
Changes discussed below.
ErrorHandling
The previous
AnomalyHandlingdirectory was renamed toErrorHandlingandErrors.swiftnow lives in that directory.The
AnomalyTypeenum now lives insideMetricsLoggerErrorfor consistency. This is where all other runtime errors in our package live. It made sense to make these anomalies into errors because the existingClientConfigErrortype contains runtime and configuration error values. This design allows us to expose the handling in the previous PR to handle all kinds of errors.New error enumerations and types were added alongside the anomalies that were moved over. This was for naming and value consistency. For example, we previously had only an error for
invalidWireFormat; we now have errors for invalid values for all the enums inClientConfig.Console Logging
ErrorHandlernow logs errors to console automatically, using OSLog at theerrorseverity. This functionality obeys the value set byClientConfig.osLogLevel. Separate classes don't need to console log their errors; this is now done inErrorHandler.As a result of this, we now create
ErrorHandlereven ifmetricsLoggingErrorHandlingis.none, butosLogLevelis.erroror higher.Modal Dialog and Release Builds
We now guard the strings and the ErrorModalVC with
#if DEBUGto exclude the code and resources in release builds. This adds the limitation that the dialog will only appear in debug builds, which limits their audience. Even so, it still makes sense to add this guard, because:This also means that setting
ClientConfig.metricsLoggingErrorHandlingto.modalDialogor higher in a release build is a no-op. It still makes sense to include the setting though, since it's exposed inClientConfig, and hence to Remote Config as well.