直接在 Flutter Clean 架构中的故障类中使用 Firebase Crashlytics？

Question

我正在探索 Flutter 干净的架构和错误处理，我设置了抛出的自定义 Exception 类，以及这些异常的特定 Failure 类。

现在，我遇到了一种情况，需要处理未捕获的异常。为了解决这个问题，我使用了 catch 块，对于未捕获的异常，我使用了 UnknownFailure 类。不过，我还想向 Crashlytics 报告这些未捕获的异常。为了实现此目的，我在 UnknownFailure 类中添加了一个报告方法，该方法使用 Firebase Crashlytics 实例来报告异常。

我不确定根据干净的架构指南直接在 Failure 类中使用 Firebase 实例是否被认为是良好实践。你怎么认为？继续这种方法是否可以接受，还是我应该考虑其他方法？

异常类 -

class IsarDBException implements Exception {}

class InAppUpdateException implements Exception {}

失败课程

  class Failure extends Equatable {
  final String message;

  const Failure({
    this.message = 'An error occurred.',
  });

  @override
  List<Object?> get props => [];
}

class LocalDBFailure extends Failure {}

class InAppUpdateFailure extends Failure {}

class PackageInfoFailure extends Failure {}

class UnknownFailure extends Failure {
  void report(dynamic exception, StackTrace stack) {
    FirebaseCrashlytics.instance.recordError(exception, stack,fatal: true);
  }
}

服务等级-

AsyncResult<bool> checkForUpdate() async {
    try {
      var result = await inAppUpdateRepository.checkForUpdate();
      return Result.success(result);
    } on IsarDBException {
      return Result.error(LocalDBFailure());
    } catch (exception, stack) {
      var failure = UnknownFailure();
      failure.report(exception, stack);
      return Result.error(failure);
    }
  }

Answer 1

在我看来，异常或失败应该只是表明某些错误的信息对象。其中有逻辑，比如你的报告方法，是我在任何项目中从未见过的。您的服务类似乎负责应用程序逻辑，并且在我看来应该处理报告。此外，我不会对 FirebaseCrashlytics 这样的库进行硬编码。抽象依赖关系（依赖倒置原则）是一种很好的做法。在这种情况下，您可以实现一个接受失败的报告接口，并且其中一个实现可以使用您对 FirebaseCrashlytics 的调用。这还有一个优点，您可以在服务测试中使用此接口的模拟或假实现。