similar to: re-throwing an interrupt condition

I don't want to return a value, I want to interrupt the computation, that's why I need to re-throw . But before getting back to the user I want to run some cleanup code. G. On Sat, Jul 28, 2018 at 5:59 PM I?aki ?car <i.ucar86 at gmail.com> wrote: > > El s?b., 28 jul. 2018 a las 18:30, G?bor Cs?rdi > (<csardi.gabor at gmail.com>) escribi?: > > > > Anyone

The internal code does more or less signalCondition(e) ## allows for (another) handler cat("\n") ## cleans up console invokeRestart("abort") ## jump to 'abort' restart if not handled [for back compatibility it also runs the error option code if that is set, but that may go away eventually]. A version of your example: > { +

On Sat, 28 Jul 2018, G?bor Cs?rdi wrote: > I don't want to return a value, I want to interrupt the computation, > that's why I need to re-throw . > But before getting back to the user I want to run some cleanup code. If it is just cleanup you want then a finally clause or on.exit should do, and will cover all form of non-local transfer of control. Best, luke > > G. >

I'm confused by the page documenting tryCatch and friends. I think it describes 3 separate mechanisms: tryCatch (in which control returns to the invoking tryCatch), withCallHandlers (in which control goes up to the calling handler/s but then continues from the point at which signalCondition() was invoked), and withRestarts (I can't tell where control ends up). For tryCatch the docs say

On Thu, 26 Jul 2018, G?bor Cs?rdi wrote: > On Thu, Jul 26, 2018 at 12:25 PM Barry Rowlingson > <b.rowlingson at lancaster.ac.uk> wrote: >> >> On Thu, Jul 26, 2018 at 12:22 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: >>> I am trying to control a background R session, connected via a fifo / >>> named pipe. >> >> Is the fifo

Does signalCondition() only work within try-catch blocks? I expected: testSignal <- function() { error <- simpleError("An error!") signalCondition(error) } to do the same thing as testStop <- function() { error <- simpleError("An error!") stop(error) } but testSignal returns NULL without throwing an error. Have I misunderstood something?

On Thu, Jul 26, 2018 at 12:22 AM, G?bor Cs?rdi <csardi.gabor at gmail.com> wrote: > I am trying to control a background R session, connected via a fifo / > named pipe. Is the fifo significant here? If I read the same R code from a file via `<` I get the input echoed (R 3.4.4, Ubuntu). Barry

The suppressMessages and suppressWarnings functions currently suppress all the message or warnings that are generated by the input expression. The ability to suppress only specific messages or warnings is sometimes useful, particularly for cases like file import where there are lots of things that can go wrong. Suppressing only messages that match a regular expression has rightly been rejected

Thanks for tracking this down. Yeah, I should use suppressWarnings(), you are right. Although, readLines() might throw another warning, e.g. for incomplete last lines, and you don't necessarily want to suppress that. TBH I am not sure why that warning is given: ? con <- file(tempfile()) ? open(con) Error in open.connection(con) : cannot open the connection In addition: Warning message: In

Hello, 1. The Situation : ------------------------ The stack traceback is not available when error ouccured in a try(....) -- test.R -------------------------------- f<-function(a){ return ( log(a) ) } try(f("A")) traceback() ------------------------------------------- I get the following message : > try(f("A")) Error in log(x) : Non-numeric argument to mathematical

OK, I managed to create an example without callr, but it is still somewhat cumbersome. Anyway, here it is. Terminal 1: mkfifo fif R --no-readline --slave --no-save --no-restore < fif Terminal 2: cat > fif Sys.getpid() This will make Terminal 1 print the pid of the R process, so we can send a SIGINT: Terminal 3: kill -INT pid The R process is of course still running happily. Terminal 2

On Thu, Dec 14, 2017 at 7:56 PM, Gabriel Becker <gmbecker at ucdavis.edu> wrote: > Gabor, > > You can grab the connection and destroy it via getConnection and then a > standard close call. Yeah, that's often a possible workaround, but since this connection was opened by readLines() internally, I don't necessarily know which one it is. E.g. I might open multiple

Hi all, The help for traceback states: Errors which are caught _via_ 'try' or 'tryCatch' do not generate a traceback, so what is printed is the call sequence for the last uncaught error, and not necessarily for the last error. Is there any way to get a traceback (or something similar) for an error raised inside a try block? Regards, Hadley -- http://had.co.nz/

Unfortunately --interactive also makes the session interactive(), which is bad for me, as it is a background session. In general, I don't want the interactive behavior, but was wondering if I could send as SIGINT to try to interrupt the computation of the background process, and if that does not work, then I would send a SIGKILL and start up another process. It all works nicely, except for

Hi Luke, Thank you for your response. On 6/21/19 10:56 AM, Tierney, Luke wrote: Thanks for the suggestion. However I don't think it is the right way to go. I also don't care for what install.packages() does. Signaling a warning and then an error means someone has to catch both the error and the warning, or suppress the warning, in order to handle the error programmatically. I do care

Hi. Using Rterm v2.2.1 on WinXP, is there a way to interrupt a call like repeat { readline() } without killing the Command window? Ctrl+C is not interrupting the loop: R : Copyright 2006, The R Foundation for Statistical Computing Version 2.2.1 Patched (2006-01-01 r36947) <snip></snip> > repeat { readline() } ^C ^C ^C ^C On Unix it works. The problem seems to get the

With tryCatch() it is possible to catch interrupts with tryCatch(). Then you can use a 'finally' statement to clean up, release resources etc. However, how can I "protect" against additional interrupts? This is a concern when the hold down Ctrl+C and generates a sequence of interrupts. Example: tryCatch({ cat("Press Ctrl+C...\n"); Sys.sleep(5); }, interrupt =

Thank you Luke for prompt reply. Is it possible then to request a new function to R C API "message" that would equivalent to R "message" function? Similarly as we now have C "warning" and C "error" functions. Best, Jan On Sun, Sep 15, 2019 at 5:25 PM Tierney, Luke <luke-tierney at uiowa.edu> wrote: > > On Sun, 15 Sep 2019, Jan Gorecki wrote:

The following example involves a function whose on.exit() expression both generates an error and catches the error. The body of the function also generates an error. When calling the function wrapped in a tryCatch, should that tryCatch's error function be given the error from the body of the function, since the one from the on.exit has already been dealt with? Currently the outer tryCatch

Dear R-devel community, There appears to be an inconsistency in R C API about the exceptions that can be raised from C code. Mapping of R C funs to corresponding R functions is as follows. error -> stop warning -> warning REprintf -> message Rprintf -> cat Rprint/cat is of course not an exception, I listed it just for completeness. The inconsistency I would like to report is