Daniel Shahaf wrote:
> Someone on IRC got "E200030: I/O error", which prompted me to write
> a patch that exposes the sqlite integer error code via the error string
> (the err->apr_err value remains unchanged, 200030 SVN_ERR_SQLITE_ERROR).
>
> Any objections in principle, or should I go ahead and see how many tests
> this breaks?
No objections, just an improvement:
> @@ -739,8 +743,8 @@ init_sqlite(void *baton, apr_pool_t *pool)
> {
> int err = sqlite3_config(SQLITE_CONFIG_MULTITHREAD);
> if (err != SQLITE_OK && err != SQLITE_MISUSE)
> - return svn_error_create(SQLITE_ERROR_CODE(err), NULL,
> - _("Could not configure SQLite"));
> + return svn_error_createf(SQLITE_ERROR_CODE(err), NULL,
> + _("Could not configure SQLite (%d)"),
> err);
In cases like this one, it seems we should be using one of the above sqlite ->
svn error converters so that we get the full SQLite description, and then
wrapping the resulting svn error object with "Could not configure SQLite".
- Julian
