This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 01/15 v3] Introduce common/errors.h


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;


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]