On Fri, 24 Sep 2021 07:49:44 -0700
Roy Mendelssohn - NOAA Federal via R-package-devel
wrote:
> All internet calls are wrapped in 'try()'. If that shows an error,
> I write a message to the screen about the error, and call stop(),
> perhaps with a further message in that call. Somehow this do
try/stop is in the operational code. But it is easy enough to make it so that
the code always returns something, even when there is an internet access
problem.
As I said, if "failing gracefully" and ever actually been defined with
examples life would have been much easier for a number of pac
Roy,
> All internet calls are wrapped in 'try()'. If that shows an error, I
> write a message to the screen about the error, and call stop(),
> perhaps with a further message in that call.
out of ignorance, i ask ...
in your package's operational code ("its API", or whatever), when a
required i
Not off-hand. it is weird that the only error is on Solaris. I do test on the
r-hub Solaris before submission. But at the same time, given some of the
responses that I have received (which I thank) I probably don't meet the CRAN
idea of "graceful". Easy enough for me to change as I am catch
Can you tell if the failure to download was due to a Solaris-specific issue
or due to the Solaris test machine not being fully connected to the
internet?
-Bill
On Fri, Sep 24, 2021 at 7:50 AM Roy Mendelssohn - NOAA Federal via
R-package-devel wrote:
> Hi All:
>
> I am getting dinged again on CR
Thanks to all who replied. I want to especially point out Maelle's response
because as I said I am not the first person to raise this question in terms of
accessing internet resources. Yes, graceful is in the eye of the beholder,
which i why such guidelines are really helpful.
-Roy
> On Se
On 24/09/2021 11:27 a.m., Roy Mendelssohn - NOAA Federal via
R-package-devel wrote:
Just so I am clear, I should not call stop(), but instead call a return() and
return something or other (there is nothing to skip to - it is doing a data
download and either it works or it failed). Is there
Grace is in the eyes of the beholder.
Using stop in your functions can be perfectly valid. But within the context of
examples or tests you need to catch those errors because one key definition of
success in normal building of a package is that no uncaught errors occur. So
either don't call thos
Hi,
Regarding Solaris, while the criteria is unknown, it seems Solaris can
be excluded from the CRAN check targets when there's a good reason not
to support Solaris. My package got a failure on Solaris check and I
resubmitted with the following comment, then Solaris disappeared from
the check resu
Just so I am clear, I should not call stop(), but instead call a return() and
return something or other (there is nothing to skip to - it is doing a data
download and either it works or it failed). Is there a preferred something to
return? And it is okay to write a message to the screen?
I think you're not supposed to stop().
You should just proceed with the other tests (skipping any
tests/examples that depend on access to the inaccessible internet
resources, or values derived from the failing call, to work)
Does that help?
On 9/24/21 10:49 AM, Roy Mendelssohn - NOAA F
Hi All:
I am getting dinged again on CRAN (just Solaris for some reason), and the
problem is how to exit if there is a failure of accessing the resource, I know
it has been discussed here before, but I just am not understanding what is
desired to end properly. As I have been reminded:
'Pac
12 matches
Mail list logo
