Reporting Crashes
Manual Crash Reporting
You can use the following method and API to manually report any error or exception that you handle in your code and assign it a severity level.
You can now choose between two modes for the stack trace when reporting manual exceptions and errors: Full stack trace and Current thread only.
Full Stack Trace
The default mode for stack trace reporting is Full stack trace, which provides a complete stack trace for the error, including information about all threads. This mode is useful when you need to identify the exact cause of the error, as it provides a detailed view of the code execution flow.
Current Thread Only
The new mode for stack trace reporting is the Current thread only, which provides a stack trace for the current thread only. This mode is useful when you need to optimize the performance of their application, as it provides a lighter-weight option for reporting errors.
Report Exception
To report exceptions manually, use the following methods:
let exception = NSException(name: NSExceptionName("some_exception"), reason: "Exception reason")
if let nonFatalException = CrashReporting.exception(exception) {
nonFatalException.stackTraceMode = .full
nonFatalException.report()
}NSException *exception = [NSException exceptionWithName:@"some_exception" reason:@"Exception reason" userInfo:nil];
LCQNonFatalException *nonFatalException = [LCQCrashReporting exception:exception];
nonFatalException.stackTraceMode = LCQNonFatalStackTraceModeFull;
[nonFatalException report];Report Error
To report errors manually, use the following methods:
Adding Levels to Exception & Errors
You can set different levels for manually reported exceptions using the following API:
Exceptions
Errors
Severity Levels
Here are the different severity levels available for exceptions and errors. In case no level is indicated, the default level would be error.
Performance Improvement
On average, it takes 5ms less to capture a stack trace while using CallerThread.
Modifying Stacktraces for Handled Errors
If you use a wrapper function to send handled errors, you can trim the wrapper function from the event’s stack trace. This will help you in having a more readable stacktrace.
Grouping
When an already existing crash occurs once more for any user, that crash is reported as an occurrence in the original entry. However, in order to calculate whether a crash already exists and needs to be grouped, Luciq generates a fingerprint based on attributes used in the grouping logic.
The default Luciq grouping algorithm uses a mix of the exception and stack trace information. In some cases, you might want to change how the issues are grouped together using custom grouping or fingerprints.
Crash-to-Screen Assignment Logic
When a crash occurs during a screen transition, Luciq assigns the crash to a specific screen based on the timing of the viewDidAppear and viewDidDisappear lifecycle events. The crash will be attributed to the screen name that was last set by the SDK before the crash occurred.
Custom Grouping
Required dSYM Files
Please note that in order for custom grouping to be applied, dSYM files are required to be uploaded first; otherwise, default grouping will be applied. For more information on uploading dSYM files, please visit the symbolication page.
One way to customize how crashes are grouped together is by providing Luciq with packages that you would like us to ignore from our default grouping logic. If you define a package to be ignored, Luciq will skip the frame with that package and move on to find the next one that is not on your ignored list. This is done on an application level by going to your Application → Settings → Custom Crash Grouping.
Expected Input:
Path
Binary Image
Paths will be evaluated on a starts with basis, while Binary Images will be evaluated on an equality basis.
Examples:
Path =
Luciq-- Ignores =Luciq,Luciq/CrashReporting,Luciq/APMPath =
Luciq/APM-- Ignores =Luciq/APM,Luciq/APM/AppLaunch-- Doesn't Ignore =Luciq,Luciq/CrashReportingBinary Image =
BinaryImage-- Ignores =BinaryImage-- Doesn't Ignore =BinaryImage2,Binaryimage
Sample Stack Trace:
Without custom grouping, Luciq would group the crash based on
ThirdParty -[LoggerManager LogArray:] + 80since it's the first non-system frameWith custom grouping while ignoring path
home/files/ThirdParty/and binary imageThirdParty, we will skip the first frameThirdParty -[LoggerManager LogArray:] + 80, and the crash will be grouped based onMyapp - ViewController tableView:didSelectRowAtindexPath:.
Custom Fingerprinting
Overriding the default grouping
Please note that using custom fingerprinting will override Luciq's default grouping by sending a fingerprint string.
In the event that you'd like to report the exception manually with a custom grouping fingerprint in mind, you can use the below APIs to do just that.
Last updated