From e8ea2aebe7af3572802c484ec1361dc1b04c16c1 Mon Sep 17 00:00:00 2001 From: Philip Withnall Date: Mon, 26 Aug 2019 09:32:39 +0300 Subject: [PATCH] gerror: Add a docs paragraph about not displaying errors verbatim in UI MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit It’s confusing and often doesn’t help the user. Match the error code and come up with a more UI-appropriate error message. Signed-off-by: Philip Withnall --- glib/gerror.c | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/glib/gerror.c b/glib/gerror.c index b190d6881..cf20bc8c0 100644 --- a/glib/gerror.c +++ b/glib/gerror.c @@ -114,6 +114,13 @@ * function (the file being opened, or whatever - though in the * g_file_get_contents() case, the @message already contains a filename). * + * Note, however, that many error messages are too technical to display to the + * user in an application, so prefer to use g_error_matches() to categorize errors + * from called functions, and build an appropriate error message for the context + * within your application. Error messages from a #GError are more appropriate + * to be printed in system logs or on the command line. They are typically + * translated. + * * When implementing a function that can report errors, the basic * tool is g_set_error(). Typically, if a fatal error occurs you * want to g_set_error(), then return immediately. g_set_error()