pcp
[Top] [All Lists]

Re: Derived metric issues

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: Derived metric issues
From: "Frank Ch. Eigler" <fche@xxxxxxxxxx>
Date: Sun, 21 Feb 2016 14:29:59 -0500
Cc: "'Lukas Berk'" <lberk@xxxxxxxxxx>, pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <000c01d16cdc$c8f1f4c0$5ad5de40$@internode.on.net>
References: <56B99888.2020408@xxxxxxxxxx> <56BA4445.2030404@xxxxxxxxxxxxxxxx> <8737ssptwp.fsf@xxxxxxxxxx> <y0m7fi4bo0d.fsf@xxxxxxxx> <000101d16c5b$0feb2ef0$2fc18cd0$@internode.on.net> <20160221130818.GA24969@xxxxxxxxxx> <000c01d16cdc$c8f1f4c0$5ad5de40$@internode.on.net>
User-agent: Mutt/1.4.2.2i
Hi, Ken -

> > Is it obvious that such an error must be considered "catastrophic"?
> > The string parameter is now a colon-separated path with directories
> > and/or files.  Why would we want to stop after the first "not being
> > able to open", instead of continuing?
> 
> For all the use cases I can think of, someone using this routine would be
> doing so with an expectation that the path argument contains only readable
> files and/or directories.

I see what you mean.

> There is no clearly "right" answer for all of the (low probability, I would
> expect) corner cases, so I think the behaviour I've implemented is OK until
> I hear a plausible use case where this is produces unexpected results.

I suggest that this particular error handling mode is itself a corner
case.  There are many possible causes of error.  By classifying only
some as "catastrophic" - and not definining that term but rather
listing just one examplar, an application programmer can't use the
negative RC any differently than a zero RC.  It does not really convey
actionable information.

- FChE

<Prev in Thread] Current Thread [Next in Thread>