Fix database#execute_batch2 errors

[wishdev]

I would like to get better errors back from execute_batch2 - currently it simply returns RuntimeError and does not utilize even the basic exceptions from errors.rb

It's simple enough to make that pull request - but it would break anyone currently rescuing on RuntimeError because SQLite3::Exception's is a subclass of StandardError.

Absent a desire to make a breaking change - would changing SQLite3::Exception to be a subclass of RuntimeError be palatable at all? That would break no one because RuntimeError is a subclass of StandardError so anyone rescuing on StandardError would see no change.

Also, while in here would there be any objection to adding the 71 extended errors as specific exceptions? They would all be subclasses of the current exception that is thrown when they occur so this would be a non-breaking change which would add more clarity.

Thanks for considering this......

[tenderlove]

Hi @wishdev,

I don't think we should change the exception hierarchy. SQLite3::Exception should inherit from StandardError because that's what a bare rescue will catch. A bare rescue will also catch a RuntimeError, and I think it's relatively rare to specifically rescue RuntimeError. We should just fix execute_batch2 to raise the appropriate exception rather than RuntimeError. Additionally, the main branch is 2.0.0, so I think it's ok to make a "breaking change" like this.

Also, while in here would there be any objection to adding the 71 extended errors as specific exceptions? They would all be subclasses of the current exception that is thrown when they occur so this would be a non-breaking change which would add more clarity.

I think I'm OK with this. @flavorjones wdyt?

[flavorjones]

We should just fix execute_batch2 to raise the appropriate exception rather than RuntimeError

Agree! Will do that work today.

would there be any objection to adding the 71 extended errors as specific exceptions

Is there specific recovery behavior that you want to implement for any of these exceptions that would justify specializing more than just the error message? I'm hesitant to introduce 71 new exception classes (and maintain this by adding new ones over time) without a compelling reason.

[tenderlove]

I'm hesitant to introduce 71 new exception classes (and maintain this by adding new ones over time) without a compelling reason.

I was a bit concerned about this too. Maybe we could add a numeric error code to the exception? 🤷

[flavorjones]

Maybe we could add a numeric error code to the exception

I believe we already do:

void
rb_sqlite3_raise(sqlite3 *db, int status)
{
    // ...
    klass = rb_exc_new2(klass, sqlite3_errmsg(db));
    rb_iv_set(klass, "@code", INT2FIX(status));
    rb_exc_raise(klass);
}

See #490 for latest version of that code that returns SQLite3::Exception correctly if the code isn't matched in the switch statement.