Best practices for error handling

[ChristophKaser]

First of all, let me say that I really love GRDB and GRDBQuery - it makes dealing with persistence and writing database queries so much easier and more flexible than SwiftData!

Now to my question: Do you have any recommendations or best practices for error handling in the Queryable implementations?

I started with GRDBQuery 0.8.0 and found that errors in my queries (such as accessing the wrong columns) were simply ignored, which made debugging a bit difficult. To work around this, I wrote my publisher methods like this

func publisher(in database: AppDatabase) -> AnyPublisher<[Customer], Never>  {
        return ValueObservation
            .tracking(fetchValue(_:))
            .publisher(in: database.reader, scheduling: .immediate)
            .assertNoFailure() // assertNoFailure to make sure any SQL error causes a fatalError that will trigger an XCode breakpoint / sentry logging
            .eraseToAnyPublisher()
    }

I am now in the process of migrating to GRDBQuery 0.10.0 and have seen that the @Queryproperty wrapper now contains an error property I can access to see whether an error has occurred. However, that would require special code in each View that contains a @Query property.

Am I wrong in thinking that errors in a GRDBQuery should not normally occur unless I made a mistake when writing the query? Should I handle errors more gracefully than calling fatalError?

Do you think it would be a good idea to add an assertNoFailure option to QueryableOptions that causes errors to be treated as fatal?

Thanks for any tips you can give! :)

[groue]

Hello @ChristophKaser,

Thanks for migrating to 0.10.0, where apps can detect if an error happens. I'm not sure there is a good answer about handling them yet, because:

Am I wrong in thinking that errors in a GRDBQuery should not normally occur unless I made a mistake when writing the query? Should I handle errors more gracefully than calling fatalError?

Since we're dealing with read-only queries, errors should generally be a programmer error (an invalid query that requires code to be changed), or an I/O error. I/O can always fail, unfortunately. I/O error can happen on locked device in the background, due to data protection, for example.

I personally never had to deal with such errors, and this explains the somewhat dire state of error handling in GRDBQuery.

assertNoFailure is not a bad option, because at least you'll get a crash report in case of error, instead of the default behavior which is a silent failure.

Maybe, in crucial views like the boot screen, you might want to check the error property of @Query?

[ChristophKaser]

Hello @groue,

wow, that was fast! Thank you for your answer!
I think it makes sense to check for I/O errors in the boot screen (so a locked device state is handled gracefully) and throw fatalErrors to generate crash reports otherwise.

If you don't mind, I will try to write a PR that adds the assertNoFailure option.

Best regards,
Christoph

[groue]

Thank you @ChristophKaser,

If you don't mind, I will try to write a PR that adds the assertNoFailure option.

I'm not sure I understand. Do you want to modify the library?

[ChristophKaser]

Yes, that was what I meant with

Do you think it would be a good idea to add an assertNoFailure option to QueryableOptions that causes errors to be treated as fatal?

I am trying to migrate my queries to ValueObservationQueryable. However, when I use this protocol, I have no way of calling assertNoFailure since I am not in control of creating the combine publisher. Therefore I proposed a new option that would call this method on the publisher.

[ChristophKaser]

I have created PR #64 to demonstrate my idea.

[groue]

OK, thank you, I better understand. See you in #64.