Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #146098

Re: error_t proposal

From Ike Naar <ike@iceland.freeshell.org>
Newsgroups comp.lang.c
Subject Re: error_t proposal
Date 2019-09-09 07:35 +0000
Organization A noiseless patient Spider
Message-ID <slrn3km4qnc062.f0h.ike@iceland.freeshell.org> (permalink)
References (12 earlier) <lnpnkdrqfk.fsf@kst-u.example.com> <32ae196a-b38b-43e4-a09d-561a5d2e5aa6@googlegroups.com> <VHEcF.199857$9i3.11349@fx42.iad> <slrn3ht8qnaob4.fpt.ike@sdf.lonestar.org> <6agdF.238076$Yo.220135@fx08.iad>

Show all headers | View raw


On 2019-09-08, Clifford Heath <no.spam@please.net> wrote:
> On 9/9/19 6:15 am, Ike Naar wrote:
>> On 2019-09-07, Clifford Heath <no.spam@please.net> wrote:
>>> On the other hand one could augment the existing contract.
>>>
>>> For example, an ENOSPC error while writing a file can still be set in
>>> errno, but a support library could also set an additional variable
>>> (error parameter) to the name of the device that is out of space. Even
>>> just an fstat() to get the inode details from the fd would be a damn
>>> good start.
>> 
>> Is this really necessary?
>> If some function, taking a file argument, returs ENOSPC, the caller
>> knows the file for which error condition happened, so if the caller
>> would be interested in the device, the caller could extract this
>> information via other means.
>
> Yes, it is necessary, both in this case and in other cases, even though 
> there may be a round-about way of discovering the cause.
>
> The culture of laziness that engendered this omission is the same 
> culture that results in omission of other detail, caricatured eventually 
> by "Unknown Error 0x80000000" type reporting. It's too hard to handle 
> every error that might follow from a write() call, so coders end up 
> simply saying "Can't save your project" or something even less useful, 
> and leaving the end user guessing at why.
>
> Every single error has a concrete context and cause, and we need to make 
> a radical commitment to actually reporting the details (all the time but 
> most particularly at the operating system level) - as well as the final 
> consequences. Failure to properly report details that are available is 
> the single thing that most infuriates users, and rightly so.
>
> This is why our users hate us.

If the caller of write() is not willing to report the details when
write() returns an error, then what would be the benefit if write()
would provide those details in some alternative fashion?

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-04 14:14 -0700
  Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-04 15:20 -0700
    Re: error_t proposal Mateusz Viste <mateusz@wont.tell> - 2019-09-05 08:02 +0000
      Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:04 -0700
        Re: error_t proposal Bruce S <bruces42@hotmail.com> - 2019-09-05 08:18 -0600
          Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:31 -0700
            Re: error_t proposal James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-09-05 17:49 -0400
              Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 15:14 -0700
            Re: error_t proposal Bruce S <bruces42@hotmail.com> - 2019-09-06 14:03 -0600
  Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-05 09:30 +1000
    Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 02:38 -0700
    Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:57 -0700
      Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 05:16 -0700
        Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 05:35 -0700
          Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 06:08 -0700
            Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-05 06:16 -0700
              Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 06:37 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 07:04 -0700
                Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-05 20:51 +0100
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 13:52 -0700
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:56 -0700
              Re: error_t proposal William Ahern <william@25thandClement.com> - 2019-09-05 13:18 -0700
              Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:25 +1000
      Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:35 +1000
        Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 04:22 -0700
    Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-05 13:59 +0000
      Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-06 07:10 +1000
  Re: error_t proposal Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-05 10:01 +0000
    Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 04:36 -0700
      Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-05 14:43 -0700
        Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 05:01 -0700
          Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 11:18 -0700
            Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-06 19:34 +0000
            Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 12:37 -0700
              Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-06 20:54 +0100
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 13:20 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 13:43 -0700
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 14:25 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 15:14 -0700
                Re: error_t proposal Keith Thompson <kst-u@mib.org> - 2019-09-06 15:49 -0700
                Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-06 18:44 -0700
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-07 12:35 +1000
                Re: error_t proposal Ike Naar <ike@sdf.lonestar.org> - 2019-09-08 20:15 +0000
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-09 09:30 +1000
                Re: error_t proposal Ike Naar <ike@iceland.freeshell.org> - 2019-09-09 07:35 +0000
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-09 19:44 +1000
                Re: error_t proposal scott@slp53.sl.home (Scott Lurndal) - 2019-09-09 13:58 +0000
                Re: error_t proposal Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-09-10 14:24 +0000
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-11 09:22 +1000
                Re: error_t proposal Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2019-09-10 16:48 -0700
                Re: error_t proposal Clifford Heath <no.spam@please.net> - 2019-09-11 10:45 +1000
                Re: error_t proposal Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-09-06 21:47 +0100
  Re: error_t proposal jadill33@gmail.com - 2019-09-05 07:04 -0700
    Re: error_t proposal Thiago Adams <thiago.adams@gmail.com> - 2019-09-05 07:36 -0700
      Re: error_t proposal jadill33@gmail.com - 2019-09-05 08:43 -0700

csiph-web