From: Gary Benson <gbenson@redhat.com>
To: Pedro Alves <palves@redhat.com>
Cc: Doug Evans <dje@google.com>,
gdb-patches <gdb-patches@sourceware.org>,
Tom Tromey <tromey@redhat.com>
Subject: Re: [PATCH 01/15 v3] Introduce common/errors.h
Date: Fri, 18 Jul 2014 09:20:00 -0000 [thread overview]
Message-ID: <20140718090630.GA17917@blade.nx> (raw)
In-Reply-To: <53C7F5D6.6060102@redhat.com>
Pedro Alves wrote:
> On 07/17/2014 04:39 PM, Gary Benson wrote:
> > Pedro Alves wrote:
> > > On 07/17/2014 02:47 PM, Gary Benson wrote:
> > > > +/* Throw an error. The current operation will be aborted. The
> > > > + message will be issued to the user. The application will
> > > > + return to a state where it is accepting commands from the user. */
> > >
> > > These comments aren't really true, though. We have plenty of
> > > places catching errors with TRY_CATCH and proceeding without
> > > returning to a state where we're accepting commands from the
> > > user.
> >
> > How about "Throw an error. The current operation will be aborted.
> > The application may catch and process the error, or, if not, the
> > message will be issued to the user and the application will return
> > to a state where it is accepting commands from the user."
>
> Still infers what the application does with the error. IMO, it's
> best to describe the interface. Like:
>
> Throw a generic error. This function not return, instead
> it executes a long jump, aborting the current operation.
> The function takes printf-style arguments, which are used to
> construct the error message.
Surely "it executes a long jump" is describing what the application
does with the error? Besides, it's not true for IPA, where error
just calls exit (1).
In the context of this whole file, you have:
- warning (one type)
- errors (three types)
- special cases (perror_with_name, malloc_failure)
The only difference between the three types of error is what the
application does with them:
- error (may be handled, may return to command level, may exit)
- fatal (will exit)
- internal_error (may return to command level, may exit)
I don't think you can properly document these functions without
spelling this out.
Also, the documentation in this file is not just for callers of the
functions, it has to document them for implementors too.
How about the following?
Cheers,
Gary
--
/* Display a warning message to the user. The message is constructed
using a printf-style format string and a printf- or vprintf-style
argument list. */
extern void warning (const char *fmt, ...) ATTRIBUTE_PRINTF (1, 2);
extern void vwarning (const char *fmt, va_list args)
ATTRIBUTE_PRINTF (1, 0);
/* Throw a non-fatal error, constructing the message using a printf-
style format string and a printf- or vprintf-style argument list.
This function does not return. The application may attempt to
handle the error. */
extern void error (const char *fmt, ...)
ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);
extern void verror (const char *fmt, va_list args)
ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0);
/* Throw a non-fatal error, constructing the message by combining
STRING with the system error message for errno. This function does
not return. The application may attempt to handle the error. */
extern void perror_with_name (const char *string) ATTRIBUTE_NORETURN;
/* Throw a fatal error, constructing the message using a printf-style
format string and a printf- or vprintf-style argument list. This
function does not return. The application will exit. */
extern void fatal (const char *fmt, ...)
ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2);
extern void vfatal (const char *fmt, va_list args)
ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0);
/* Throw an internal error, constructing the message using a printf-
style format string and a printf- or vprintf-style argument list.
This function does not return. Internal errors indicate
programming errors such as assertion failures, as opposed to more
general errors the user may encounter. Internal errors are treated
as fatal errors, except that the application may offer the user the
choice to return to the command level rather than exiting. */
extern void internal_error (const char *file, int line,
const char *fmt, ...)
ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (3, 4);
extern void internal_verror (const char *file, int line,
const char *fmt, va_list args)
ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (3, 0);
/* A special case of internal error used to handle memory allocation
failures. */
extern void malloc_failure (long size) ATTRIBUTE_NORETURN;
next prev parent reply other threads:[~2014-07-18 9:06 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-16 16:19 [PATCH 00/15 v2] Common code cleanups Gary Benson
2014-07-16 16:19 ` [PATCH 15/15 v2] Finally remove GDBSERVER (mostly) from linux-btrace.c Gary Benson
2014-07-16 16:19 ` [PATCH 04/15 v2] Introduce common-types.h Gary Benson
2014-07-17 11:21 ` Doug Evans
2014-07-16 16:32 ` [PATCH 09/15 v2] Mostly remove GDBSERVER from linux-waitpid.c Gary Benson
2014-07-16 16:33 ` [PATCH 14/15 v2] Introduce get_thread_regcache_for_ptid Gary Benson
2014-07-16 16:45 ` [PATCH 02/15 v2] Remove some GDBSERVER checks from linux-ptrace Gary Benson
2014-07-17 8:37 ` Doug Evans
2014-07-17 16:40 ` Pedro Alves
2014-07-16 16:45 ` [PATCH 05/15 v2] Introduce and use debug_printf and debug_vprintf Gary Benson
2014-07-16 16:45 ` [PATCH 01/15 v2] Introduce common/errors.h Gary Benson
2014-07-16 18:36 ` Doug Evans
2014-07-17 13:41 ` [PATCH] " Gary Benson
2014-07-17 13:47 ` Gary Benson
2014-07-17 14:05 ` [PATCH 01/15 v3] " Gary Benson
2014-07-17 15:40 ` Pedro Alves
2014-07-17 16:03 ` Gary Benson
2014-07-17 16:19 ` Pedro Alves
2014-07-18 9:20 ` Gary Benson [this message]
2014-07-18 10:42 ` Doug Evans
2014-07-18 11:23 ` Gary Benson
2014-07-18 12:31 ` Doug Evans
2014-07-18 10:44 ` Pedro Alves
2014-07-16 16:48 ` [PATCH 06/15 v2] Remove simple GDBSERVER uses from common, nat and target Gary Benson
2014-07-16 16:48 ` [PATCH 03/15 v2] Make gdbserver CORE_ADDR unsigned Gary Benson
2014-07-17 9:02 ` Doug Evans
2014-07-17 16:42 ` Pedro Alves
2014-07-18 8:07 ` Maciej W. Rozycki
2014-07-16 17:03 ` [PATCH 13/15 v2] Finally remove GDBSERVER (mostly) from agent.c Gary Benson
2014-07-16 17:03 ` [PATCH 11/15 v2] More target unification Gary Benson
2014-07-16 17:03 ` [PATCH 08/15 v2] Make btrace-common.h not use GDBSERVER Gary Benson
2014-07-16 17:04 ` [PATCH 10/15 v2] Add target/target.h Gary Benson
2014-07-16 17:20 ` [PATCH 12/15 v2] Add target/symbol.h, update users Gary Benson
2014-07-16 17:24 ` [PATCH 07/15 v2] Remove GDBSERVER use from nat/i386-dregs.c Gary Benson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140718090630.GA17917@blade.nx \
--to=gbenson@redhat.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
--cc=palves@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox