public inbox for linux-raid@vger.kernel.org
 help / color / mirror / Atom feed
From: "Tkaczyk, Mariusz" <mariusz.tkaczyk@linux.intel.com>
To: NeilBrown <neilb@suse.de>
Cc: Nigel Croxon <ncroxon@redhat.com>,
	jes@trained-monkey.org, xni@redhat.com,
	linux-raid@vger.kernel.org
Subject: Re: [PATCH V2] Fix return value from fstat calls
Date: Fri, 13 Aug 2021 09:45:25 +0200	[thread overview]
Message-ID: <fe98561f-7f8f-45fa-bafa-e7f553a0f162@linux.intel.com> (raw)
In-Reply-To: <162883915010.1695.14187049458830945568@noble.neil.brown.name>

On 13.08.2021 09:19, NeilBrown wrote:
> On Fri, 13 Aug 2021, Tkaczyk, Mariusz wrote:
>>

> Error handling that is buggy, or that is hard to maintain is not better
> than nothing.  If I can't guarantee that we never pass a bad file
> descriptor, then you cannot guarantee that the error handling has no
> bugs.   Less code generally means less bugs.
> 
> Any attempt to try to handle an error that should not be able to happen
> other than crashing is fairly pointless - you cannot guess the real
> cause, so you cannot know how to repair.  Just printing a message and
> continuing could be as bad as not checking the error.
> As error handling, I meant any error verification. It doesn't indicate
that we should return status and end gracefully. exit() is elegant
solution in this case, totally agree.

Thanks,
Mariusz


  reply	other threads:[~2021-08-13  7:45 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-10 15:15 [PATCH] Fix return value from fstat calls Nigel Croxon
     [not found] ` <ed1b0603-e523-6ca6-12ce-d30a85afe885@linux.intel.com>
2021-08-11 13:06   ` Tkaczyk, Mariusz
2021-08-11 19:09 ` [PATCH V2] " Nigel Croxon
2021-08-11 22:52   ` NeilBrown
     [not found]     ` <346e8651-d861-45c7-9058-68008e691b93@Canary>
2021-08-12 23:23       ` NeilBrown
2021-08-13  7:00         ` Tkaczyk, Mariusz
2021-08-13  7:19           ` NeilBrown
2021-08-13  7:45             ` Tkaczyk, Mariusz [this message]
2021-08-13 19:19               ` Jes Sorensen
2021-08-12  6:49   ` Tkaczyk, Mariusz

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=fe98561f-7f8f-45fa-bafa-e7f553a0f162@linux.intel.com \
    --to=mariusz.tkaczyk@linux.intel.com \
    --cc=jes@trained-monkey.org \
    --cc=linux-raid@vger.kernel.org \
    --cc=ncroxon@redhat.com \
    --cc=neilb@suse.de \
    --cc=xni@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