Как разделить / разгруппировать отчет о нефатальных исключениях Crashlytics с помощью настраиваемого атрибута?

Я отправляю в Crashlytics ошибки, возникающие при синхронизации с сервером. Эти ошибки в основном содержат информацию о различных конфликтах данных. Все ошибки заключены в один класс исключений, в котором есть поля типа apiErrorCode. Я не могу создать отдельный класс исключений для каждой ошибки, потому что их очень много. Итак, все такие исключения, которые я отправляю с помощью Crashlytics.logException(), сгруппированы в один отчет на панели инструментов. Поэтому я должен перейти в раздел «Все сеансы» и исследовать там ошибки одну за другой, что неудобно. Также я не могу закрыть и заблокировать некоторые типы ошибок, которые не хочу видеть в отчетах (например, некоторые ожидаемые ошибки сервера). Можно ли вручную установить стратегию группировки Crashlytics (в моем случае на основе apiErrorCode)?


android crashlytics google-fabric crashlytics-android crash-reports
person Bringoff    schedule 27.09.2017    source источник

Ответы (2)


arrow_upward
6
arrow_downward

Если у вас есть разные типы исключений, исходящие из одной трассировки стека, вы можете изменить трассировку стека, добавив еще один настраиваемый элемент вверху:

public class CustomException extends Exception {

    public CustomException(String message, int lineNumber) {
        super(message);
        StackTraceElement[] stackTrace = getStackTrace();
        StackTraceElement[] newStackTrace = new StackTraceElement[stackTrace.length + 1];
        System.arraycopy(stackTrace, 0, newStackTrace, 1, stackTrace.length);
        newStackTrace[0] = new StackTraceElement("className", "methodName", "fileName", lineNumber);
        setStackTrace(newStackTrace);
    }
}
person Andoctorey    schedule 05.10.2018

arrow_upward
2
arrow_downward

Майк из Fabric здесь. Невозможно переопределить группировку, которую мы выполняем по зарегистрированным ошибкам. Я рекомендовал указывать конкретный тип исключения и сообщение вместо использования одного класса исключения, хотя это связано с повышением сложности кода.

person Mike Bonnell    schedule 27.09.2017
comment
Спасибо за Ваш ответ. Попытаюсь что-то сделать с пользовательскими типами исключений, хотя это довольно сложно, потому что существует около 120 кодов ошибок, и нашему приложению не нужно обрабатывать большинство из них, а просто отображать сообщение об исключении, полученное с сервера. Сообщения об исключениях различны для каждого ответа API. Но, как я понимаю, Crashlytics не принимает это во внимание. Это было бы хорошо. На самом деле, настраиваемая группировка тоже была бы неплохим запросом :) - person Bringoff; 28.09.2017
comment
Спасибо за подробности и отзывы! У нас нет ближайших планов по добавлению пользовательской группировки, но мы поделимся вашим желанием с командой. - person Mike Bonnell; 28.09.2017
comment
В проекте Android я использую Timber и Timber.e, а затем использую версию TimberTree для override fun log(priority: Int...) { if (priority == ERROR) Crashlytics.logException(t ?: Exception(message)) }. Проблема в том, что все журналы сваливаются в кучу. Было бы неплохо, если бы вы могли сделать что-то вроде запроса, чтобы ткань игнорировала определенные части трассировки журнала, такие как timber.log.Timber и com.my.app.TimberTree, чтобы разделить нефатальные ошибки. - person TTransmit; 21.09.2018