| Age | Commit message (Collapse) | Author |
|
Xapian exceptions are swallowed and turned into default return value.
|
|
The catch block either needs to return, or the function needs to
return "status". Choose the latter for consistency with
n_d_get_config.
|
|
Error status is currently lost.
|
|
Xapian exceptions seem to handled OK, at least for this case.
|
|
Existing error handling seems adequate, if not ideal.
|
|
At least this Xapian exception is caught. Make sure it stays that way.
|
|
The error message and name were confusing when called in some "read
only" context.
|
|
The current error message is a bit confusing; fix in next commit.
|
|
The API docs promise to handle relative filenames, but the code did
not do it.
Also check for files outside the mail root, as implied by the API
description.
This fixes the bug reported at
id:87sgdqo0rz.fsf@tethera.net
|
|
The current code seems to look for the path relative to the current
working directory, rather than the mail store root.
|
|
Current exception handling seems OK, at least for this case.
|
|
At least this exception is already handled correctly.
|
|
This function only accesses data cached by notmuch, so being closed is
not a problem.
|
|
Xapian currently succeeds to begin/end a transaction on a closed database,
or at least does not throw an exception. Make the test robust against
this changing.
|
|
The logic is that if it's acceptable to return SUCCESS for read only
database, it's acceptable for a closed one.
|
|
Also clarify documentation of error return from n_d_needs_upgrade.
|
|
It's a bit arbitrary which value to return for errors, but the same
argument as for read only databases applies for errors.
|
|
Either an open or closed database should be ok to destroy
|
|
This does not currently throw an error, and it should stay that way.
|
|
notmuch_database_get_version previously returned 0 on some errors, but
did not document this. Luckily 0 is not a valid database version.
|
|
In order to mimic the "best effort" API of Xapian to provide
information from a closed database when possible, do not
destroy the Xapian database object too early.
Because the pointer to a Xapian database is no longer nulled on close,
introduce a flag to track whether the notmuch database is open or not.
|
|
This should not crash, but it does currently.
|
|
These do not crash on a closed database, and we want to keep it that
way.
Start a new file of tests as T560-lib-error was starting to get unwieldy.
|
|
The original generic handler had an extra '%s' in the format
string. Update tests that failed to catch this because the template to
print status strings checked 'stat', which was not set.
|
|
Prevent test suite churn when reported line numbers change.
|
|
|
|
Also update the documentation for the behaviour of n_m_get_thread_id
that this fix relies on.
|
|
This is another case where the code should not call INTERNAL_ERROR.
|
|
This is actually one of the few potentially useful things you can do
with a message belonging to a closed database, since in principle you
could re-open the database.
|
|
This should be fine because the message belongs to the
database (talloc context wise).
|
|
Neither of these accesses the database, so should be safe. Add the
tests to catch any changes in exception throwing.
|
|
At least the exception we already catch should be reported properly.
|
|
The Xapian exception is actually caught here, but the NULL return is
not dealt with properly.
|
|
This function currently catches at least the obvious Xapian exceptions
and we want to keep it that way.
|
|
Boolean return values have no out-of-band-values to signal errors. The
change here is that a (somewhat unlikely) fatal error after indexing
will now be caught.
|
|
Initially the new function is mainly tested indirectly via the
wrapper.
|
|
This passes the NULL return inside _ensure_maildir_flags does not
break anything. Probably this should be handled more explicitely.
|
|
This belatedly implements Tomi's suggestion from
id:m25zaukv6u.fsf@guru.guru-group.fi
|
|
Depending on the flag, this actually can return an errror, so raise a
ruby exception if so.
|
|
This adds one more reason why _notmuch_thread_create might return
NULL, but those were not previously enumerated, so no promises are
broken.
|
|
As a side effect, we revert the switch from notmuch_bool_t to bool
here. This is because those two types are not actually compatible when
passing by reference.
|
|
This can be seen as moving an abort out of the library, into the CLI
where we can both print to stderr and shut the process down without
ill effect.
|
|
Our handling of errors is all or nothing here, but it's an improvement
on the status quo, and it avoids rippling internal API changes.
|
|
It's not very nice to return FALSE for an error, so provide
notmuch_message_get_flag_st as a migration path.
Bump LIBNOTMUCH_MINOR_VERSION because the API is extended.
|
|
Thanks to pazz for reporting the problem.
|
|
A separate conf.py and doc directory (or will be needed if someone wants
to build the bindings docs separately from notmuch.
|
|
It is getting unwieldy to pass configuration options on the
sphinx-build command line, and I anticipate further use of
conditionals.
As far as I could tell, execing a string is the idiomatic way to
emulate include in Python.
|
|
Currently I don't know of a good way of testing this, but at least in
principle a Xapian exception in _notmuch_message_{add,remove}_term
would cause an abort in the library.
|
|
The churn here is again mainly re-indentation.
|
|
Exception will be caught in next commit.
|