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()
    
}

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

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/APM

  • Path = Luciq/APM -- Ignores = Luciq/APM, Luciq/APM/AppLaunch -- Doesn't Ignore = Luciq, Luciq/CrashReporting

  • Binary 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:] + 80 since it's the first non-system frame

  • With custom grouping while ignoring path home/files/ThirdParty/ and binary image ThirdParty, we will skip the first frame ThirdParty -[LoggerManager LogArray:] + 80, and the crash will be grouped based on Myapp - ViewController tableView:didSelectRowAtindexPath:.

Custom Fingerprinting

Overriding the default grouping

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