Max T. Woodbury wrote:
> I think exception-handlers are useful in C++ but they do not
> exist in C.  They are not a cure-all in C++.

I use them in my Standard C programming.
I didn't say they were a "cure-all", just that
I prefer that approach over having every function
return status codes that must be explicitly tested.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Douglas A. Gwyn" wrote:
>
> Max T. Woodbury wrote:
> > I think exception-handlers are useful in C++ but they do not
> > exist in C.  They are not a cure-all in C++.
>
> I use them in my Standard C programming.

I don't think I missed the part of the C standard that describes
exception handlers, but I could have.  Could you cite it for me?

> I didn't say they were a "cure-all", just that
> I prefer that approach over having every function
> return status codes that must be explicitly tested.

This really doesn't change that need.  It neither adds nor removes
any requirement to check for errors.  It just provides a way to
pack additional information into the return value.  As such it can
simplify some error checks.  It also has some explanatory power
making the intent of any such checks more obvious.  (Which is why
a better name for 'isother' is needed!)

max@mtew.isa-geek.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

In <I6SdnY08Kd9j3zncRVn-1Q@comcast.com> DAGwyn@null.net ("Douglas A. Gwyn") writes:

>Undoubtedly, errno is unsatisfactory.

Works quite well for me.

>However, we don't want to be in the business of
>maintaining a registry of error codes no matter
>of what the details of the interface might be.

You have already started to do exactly this (the macro names are
important, not the associated values).

The only gripe I have is that not enough standard library functions are
*required* to set errno to a meaningful value upon failure.  If a fopen()
call fails it would be nice to be able to tell to the user (via perror
or strerror) the reason of the failure, but this is currently possible
only by relying on QoI factors.

>Several standard C functions that might fail in
>multiple ways that typically need to be handled
>differently already have well-defined error
>return values.

Far too few (I can only think of scanf and friends).

>Personally I prefer an exception-handler based
>approach.

Personally I don't want C to get anything resembling exceptions.  It was
designed as a (relatively) low level programming language where very
little happens behind the scenes and this should NOT change.  People who
want/need exceptions know where to find C++.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Dan.Pop@ifh.de
           Currently looking for a job in the European Union

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Max T. Woodbury wrote:
> "Douglas A. Gwyn" wrote:
>
>>Max T. Woodbury wrote:
>>
>>>I think exception-handlers are useful in C++ but they do not
>>>exist in C.  They are not a cure-all in C++.

    One could have functions returning an object
of type std::exception, and providing a conversion from
std::exception to bool which indicates success or failure.
Then you could still write

 if (somefunction())
 {  cout << "Didn't work"; }

    This probably isn't useful, but answers the question
asked.

    John Nagle
    Animats

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

John Nagle wrote:
>
> Max T. Woodbury wrote:
> > "Douglas A. Gwyn" wrote:
> >
> >>Max T. Woodbury wrote:
> >>
> >>>I think exception-handlers are useful in C++ but they do not
> >>>exist in C.  They are not a cure-all in C++.
>
>     One could have functions returning an object
> of type std::exception, and providing a conversion from
> std::exception to bool which indicates success or failure.
> Then you could still write
>
>         if (somefunction())
>         {  cout << "Didn't work"; }
>
>     This probably isn't useful, but answers the question
> asked.

Unfortunately you snipped the question...

it would also be slightly clearer if you could write:

    if ( iserror( somfunction()) )
    { cout << "Something went wrong!"; }

Which might or might not remove the need for yet another conversion
specification.

There are at least two big problems with exceptions as a return value
indicating success/failure.

1) There is no standard exception type in 'C'.

2) Exception objects are usually too large to pass in a register, making
   them quite a bit more expensive to use than a simple variation on int.

While you might convey additional variations on simple success or failure,
you have to use inheritance to do so.  Again this can not be done in 'C'.
I don't remember a 'successful' kind of exception either.  I'm not sure
that the equivalent to 'status_detail' or 'status_authority' could be built
into exceptions without changing the C++ standard.  I guess that you would
distinguish between simple lack of success and errors by having the
exception thrown only in the error case.

I think there is a place in both language for a status type like the one
I described.  It might even be a useful exception attribute for C++.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

First, before someone jumps all over me for posting something not relevant
to the C and C++ standards, note that this is relevant to both C and C++
and to standards, just not the current standard.  It might also be relevant
to POSIX and other languages, but there are not news groups relevant to
those topics on the news server I have access to.

============================== Content ====================================

I)   Problem Description.
II)  Relevant Art.
III) Requirements.
IV)  Open Questions.

========================= Problem Description =============================

A number of library functions return success, failure or error indicators.
The are currently specified as returning 'int'.  If they return more detail
about their failure, it is through 'errno'.  As P.J. Plauger and others
have said, 'errno' is a noisy channel.  If a better mechanism can be
defined, it might be useful, depending on its characteristics.

============================ Relevant Art =================================

Both VMS and Microsoft windows define a structured return status value
within a 32 bit integer return value.  Both these facilities include the
ability to designate success, failure and error conditions, the facility
that succeed or failed and detail code that elaborates on the source of
failure or error and may also provide additional information about success.

============================ Requirements =================================

1) Any further structuring of 'int' status return values must not require
   existing code to be changed.  In particular, the convention that zero is
   a success indicator must be preserved.

2) Success, simple failure and error conditions must be distinguished.  To
   this end functions or function like macros need to be defined that
   provide boolean tests for 'issuccess' and 'iserror'.  There are also
   four different combinations of success and error that should be
   distinguished:

   isok      == issuccess && !iserror
   iswarning == issuccess && iserror
   isfatal   == !issuccess && iserror
   isother   == !issuccess && !iserror

3) Existing conventions must be maintained:

   Value                    | issuccess | iserror
   -------------------------+-----------+---------
   0                        | true      | false
   -------------------------+-----------+---------
   EXIT_SUCCESS             | true      | false
   -------------------------+-----------+---------
   EXIT_FAILURE             | false     | ?
   -------------------------+-----------+---------
   EOF                      | false     | true

4) There should be a mechanism for providing more detail about the cause of
   the failure or error and possibly additional information about the
   success.  'status_detail' (or something like that) is a function or
   function like macro that extracts that information from the returned
   status value.

5) Because there may be different sources of status information with
   different specifications for 'details', an indication of the source of
   detail is needed.  'status_authority' is a function or function like
   macro that extracts that information from the returned status value.
   Some authorities can be pre-defined.

   A) The application program needs a status detail space of its own.
   B) The standard library needs a status detail space.
   C) The external environment (both hosted and unhosted) needs a status
      detail space.
   D) There should be a registry of additional detail spaces, but that is
      beyond the scope of this discussion.

   Note that 'errno' values make a good detail specification for the
   standard library detail space.

6) A type name - 'status_t' - should be set aside for return values with
   these properties.  It should be an alias for an integer type that is
   at least as large as an 'int'.

=========================== Open Questions ================================

1) isother is not a very descriptive of the condition being described.  In
   VMS this combination was designated an 'info' status.  'isinfo',
   'isinfomsg' or 'isfailure' might be better except that this combination
   of success and error may not be 'informational' and there is a natural
   assumption that 'isfailure' must be equivalent to simply '!issuccess'.

2) The Microsoft and VMS status facilities merge the detail specifications
   for success, warnings, errors and other into a single space.  This can
   produce confusing error reports.  The meaning of the detail information
   for each combination of success and error should probably be distinct.

3) There should be some authority designations set aside for local
   assignment and development.  This should NOT be a large faction of the
   authority designators (that is it should be << 1/2 the authority space)
   but should be larger than 1 or 2.  32 may be a reasonable lower bound
   on this.

4) While a 16 bit implementation of this facility is possible, the number
   of authorities and the amount of detail provided is considerably reduced.
   is that restriction too severe to make this facility useless?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Undoubtedly, errno is unsatisfactory.
However, we don't want to be in the business of
maintaining a registry of error codes no matter
of what the details of the interface might be.
Several standard C functions that might fail in
multiple ways that typically need to be handled
differently already have well-defined error
return values.
If you want to design and implement such a
facility, go ahead and let us know how it turns
out, and if it is a smashing succes perhaps it
would be suitable for proposing for adoption in
some future version of the C or C++ standards.
Be warned that you will need at the very least
a strerror()-like facility (hopefully using the
locale to fetch the string in an appropriate
natural language) and also some way for third
party library providers to link their codes
into your run-time database.

Personally I prefer an exception-handler based
approach.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Douglas A. Gwyn" wrote:
>
> Undoubtedly, errno is unsatisfactory.
> However, we don't want to be in the business of
> maintaining a registry of error codes no matter
> of what the details of the interface might be.

Part of that registry already exists in <cerrno> and <errno.h>.
Any error code values for other facilities can be specified
in header files that are associated with that facility.

There is a small problem with assuring that authority codes
do not conflict.  That problem can be tossed into the lap of
some other standard body, much like the way the definition of
Unicode is.  Which registry should be used is another open
question.

> Several standard C functions that might fail in
> multiple ways that typically need to be handled
> differently already have well-defined error
> return values.

Yep.  I may not have made it clear enough that this was
primarily intended for use by applications but that it
should also be usable by but not required for implementing
the standard library.

In that respect the proposal is incomplete.  There should
be an additional set of required macros:

    status_t STATUS_DEFINITION(_Bool s, _Bool e, int detail, int authority)

that calculates a return code from the specified components and

    status_t STATUS(_Bool s, _Bool e, int detail)

and is equivalent to STATUS_DEFINITION(s,e,detail,0).

(The choice of 0 is arbitrary.  Any implementation defined value could
be used in its place.  In fact 0 may not be the best default value.
It might be better if 0 is the authority code reserved to the standard
library.)

An authority code should be set aside for the standard library so that
errno values provided by the library can be converted to status_t values.
Similarly, there should be a generic authority code for errno values
provided by the host environment.  The values for these authority codes
should be included in the <cerrno> or <errno.h> headers.

> If you want to design and implement such a
> facility, go ahead and let us know how it turns
> out, and if it is a smashing succes perhaps it
> would be suitable for proposing for adoption in
> some future version of the C or C++ standards.

Such facilities do exist and were mentioned in the proposal.
I do in fact have an implementation and have found it quite
useful.  I made the proposal so I could get the reaction of
others.

> Be warned that you will need at the very least
> a strerror()-like facility (hopefully using the
> locale to fetch the string in an appropriate
> natural language) and also some way for third
> party library providers to link their codes
> into your run-time database.

Such a facility would be a useful adjunct to this one, but
involves a number of issues that do not have solutions that
can be standardized at the language level.  POSIX has an
answer to this, but it is not suitable for unhosted
implementations and may not be suitable for all hosted
implementations.  I left that problem out of the proposal
on purpose.

> Personally I prefer an exception-handler based
> approach.

I think exception-handlers are useful in C++ but they do not
exist in C.  They are not a cure-all in C++.

max@mtew.isa-geek.net

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]