| Message ID | 2aa30f536fb7ce5501d1ecf0315cbcb1c1c5ce38.1606419752.git.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | reftable library | expand |
On Fri, Nov 27, 2020 at 2:42 AM Han-Wen Nienhuys via GitGitGadget <gitgitgadget@gmail.com> wrote: > +/* > + Errors in reftable calls are signaled with negative integer return values. 0 > + means success. > +*/ This is the format of multi-line comments: /* * A very long * multi-line comment. */ > +enum reftable_error { > + /* Unexpected file system behavior */ > + REFTABLE_IO_ERROR = -2, > + > + /* Format inconsistency on reading data > + */ No need for a multi-line comment here. > + REFTABLE_FORMAT_ERROR = -3, > + > + /* File does not exist. Returned from block_source_from_file(), because > + it needs special handling in stack. > + */ Once again, and for the rest of the file.
On Thu, Nov 26 2020, Han-Wen Nienhuys via GitGitGadget wrote: > The reftable/ directory is structured as a library, so it cannot > crash on misuse. Instead, it returns an error codes. > > In addition, the error code can be used to signal conditions from lower levels > of the library to be handled by higher levels of the library. For example, a > transaction might legitimately write an empty reftable file, but in that case, > we'd want to shortcut the transaction overhead. > [...] > + static char buf[250]; > + switch (err) { > + case REFTABLE_IO_ERROR: > + return "I/O error"; > + case REFTABLE_FORMAT_ERROR: > + return "corrupt reftable file"; > + case REFTABLE_NOT_EXIST_ERROR: > + return "file does not exist"; > + case REFTABLE_LOCK_ERROR: > + return "data is outdated"; > + case REFTABLE_API_ERROR: > + return "misuse of the reftable API"; > + case REFTABLE_ZLIB_ERROR: > + return "zlib failure"; > + case REFTABLE_NAME_CONFLICT: > + return "file/directory conflict"; > [...] Not for this series, but I wonder if the eventual integration into the i18n framework in git needs some thought, seems all the (including presumably stuff show to users) UI strings are hardcoded English at the moment.
On Fri, Nov 27, 2020 at 11:25 AM Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote: > Not for this series, but I wonder if the eventual integration into the > i18n framework in git needs some thought, seems all the (including > presumably stuff show to users) UI strings are hardcoded English at the > moment. AFAIK, these are the only strings that potentially show up in the UI. If these strings need to be i18n'd. It is probably easier for git-core to provide its own version of reftable_error_str() ? Or we could remove reftable_error_str from the official API?
diff --git a/reftable/error.c b/reftable/error.c new file mode 100644 index 0000000000..1d60137ea7 --- /dev/null +++ b/reftable/error.c @@ -0,0 +1,39 @@ +/* +Copyright 2020 Google LLC + +Use of this source code is governed by a BSD-style +license that can be found in the LICENSE file or at +https://developers.google.com/open-source/licenses/bsd +*/ + +#include "reftable-error.h" + +#include <stdio.h> + +const char *reftable_error_str(int err) +{ + static char buf[250]; + switch (err) { + case REFTABLE_IO_ERROR: + return "I/O error"; + case REFTABLE_FORMAT_ERROR: + return "corrupt reftable file"; + case REFTABLE_NOT_EXIST_ERROR: + return "file does not exist"; + case REFTABLE_LOCK_ERROR: + return "data is outdated"; + case REFTABLE_API_ERROR: + return "misuse of the reftable API"; + case REFTABLE_ZLIB_ERROR: + return "zlib failure"; + case REFTABLE_NAME_CONFLICT: + return "file/directory conflict"; + case REFTABLE_REFNAME_ERROR: + return "invalid refname"; + case -1: + return "general error"; + default: + snprintf(buf, sizeof(buf), "unknown error code %d", err); + return buf; + } +} diff --git a/reftable/reftable-error.h b/reftable/reftable-error.h new file mode 100644 index 0000000000..7e55a16aac --- /dev/null +++ b/reftable/reftable-error.h @@ -0,0 +1,62 @@ +/* +Copyright 2020 Google LLC + +Use of this source code is governed by a BSD-style +license that can be found in the LICENSE file or at +https://developers.google.com/open-source/licenses/bsd +*/ + +#ifndef REFTABLE_ERROR_H +#define REFTABLE_ERROR_H + +/* + Errors in reftable calls are signaled with negative integer return values. 0 + means success. +*/ +enum reftable_error { + /* Unexpected file system behavior */ + REFTABLE_IO_ERROR = -2, + + /* Format inconsistency on reading data + */ + REFTABLE_FORMAT_ERROR = -3, + + /* File does not exist. Returned from block_source_from_file(), because + it needs special handling in stack. + */ + REFTABLE_NOT_EXIST_ERROR = -4, + + /* Trying to write out-of-date data. */ + REFTABLE_LOCK_ERROR = -5, + + /* Misuse of the API: + - on writing a record with NULL refname. + - on writing a reftable_ref_record outside the table limits + - on writing a ref or log record before the stack's next_update_index + - on writing a log record with multiline message with + exact_log_message unset + - on reading a reftable_ref_record from log iterator, or vice versa. + + When a call misuses the API, the internal state of the library is kept + unchanged. + */ + REFTABLE_API_ERROR = -6, + + /* Decompression error */ + REFTABLE_ZLIB_ERROR = -7, + + /* Wrote a table without blocks. */ + REFTABLE_EMPTY_TABLE_ERROR = -8, + + /* Dir/file conflict. */ + REFTABLE_NAME_CONFLICT = -9, + + /* Illegal ref name. */ + REFTABLE_REFNAME_ERROR = -10, +}; + +/* convert the numeric error code to a string. The string should not be + * deallocated. */ +const char *reftable_error_str(int err); + +#endif