gettext ?!
23. October 2006
While trying to add import and export of .po files in glom I try to understand how libgettext-po handles erros. In gettext-po.h:
/* Signal a problem of the given severity.
MESSAGE and/or FILENAME + LINENO indicate where the problem occurred.
If FILENAME is NULL, FILENAME and LINENO and COLUMN should be ignored.
If LINENO is (size_t)(-1), LINENO and COLUMN should be ignored.
If COLUMN is (size_t)(-1), it should be ignored.
MESSAGE_TEXT is the problem description (if MULTILINE_P is true,
multiple lines of text, each terminated with a newline, otherwise
usually a single line).
Must not return if SEVERITY is PO_SEVERITY_FATAL_ERROR. */
void (*xerror) (int severity,
po_message_t message,
const char *filename, size_t lineno, size_t column,
int multiline_p, const char *message_text);
This is a callback passed to po_write_file which is called on failure. Hmm, so this method is required not to return if “SEVERITY is PO_SEVERITY_FATAL_ERROR”. How could I do this? Of course I could call exit() but that not really good. An application should usually not die if an error occours. FATAL error occours for example, if the file is not writeable.
The only solution that came into my mind yet was to start another thread that would simply exit if something goes wrong but that is really ugly. Anyone here with better ideas? Maybe I just miss the point.
23. October 2006 at 13:56
My /usr/include/gettext-po.h (in Ubuntu Dapper) doesn’t have a po_write_file() function.
23. October 2006 at 16:14
From /usr/include/gettext-po.h in Edgy (updated from Dapper three days ago):
/* Write an in-memory PO file to a file.
Upon failure, return NULL and set errno. */
#define po_file_write po_file_write_v2
extern po_file_t po_file_write (po_file_t file, const char *filename,
po_xerror_handler_t handler);
23. October 2006 at 19:21
> Hmm, so this method is required not to return if “SEVERITY is PO_SEVERITY_FATAL_ERROR”
That is indeed a bit silly. It really does seem to require that the application (using this API) quits or crashes. I suppose you should warn the user that a fatal error happened and quit Glom. Hopefully it’s very very rare, and there’s no point worrying too much about something that isn’t going to happen.
You might also try to find out who added that function (by looking at a ChangeLog, for instance), and ask him. But I’d leave it until later, if at all.