Início / coding / Perguntas / 79426844
Accepted
jslth
Asked: 2025-02-10 18:51:56 +0800 CST

Controle o posicionamento de nova linha de base::stop()

  • 772

Gostaria de escrever uma função de erro personalizada em R que usa uma formatação mais consistente de mensagens de erro. No R base, os erros são formatados de uma forma que coloca mensagens de erro em uma nova linha se ela exceder a largura do console e a recua em dois espaços:

abort <- function(msg) stop(msg)
> abort("This is a very very very very long error message")
# Error in abort("This is a very very very very long error message") : 
#   This is a very very very very long error message

Se não exceder a largura do console, será colocado diretamente atrás da chamada:

> abort("Short message")
# Error in abort("Short message") : Short message

Na minha função de erro personalizada, pretendo manter a formatação mais consistente sempre iniciando as mensagens de erro em uma nova linha (semelhante ao cliformato de erro do pacote):

abort <- function(msg) stop("\n", msg)

Entretanto, ao usar esta função com uma mensagem de erro muito longa (ou uma chamada longa), a formatação de erro base do R adiciona uma nova linha e, portanto, espaços em branco indesejados à saída do erro.

> abort("This is a very very very very very very very very long error message")
# Error in abort("This is a very very very very very very very very long error message") : 
#   
# This is a very very very very very very very very long error message

Existe alguma maneira de controlar esse comportamento, suprimindo-o ou descobrindo quando ele ocorre para contorná-lo manualmente?

2 respostas

  1. Best Answer

    É fácil o bastante suspender temporariamente a impressão de mensagens de erro com options(show.error.messages = FALSE), então imprima qualquer mensagem que você quiser no console. Depois disso, você pode lançar um erro usando um simples stop(msg)para interromper a execução, e somente sua própria mensagem personalizada aparecerá.

    O problema fatal com essa abordagem é que depois que o programa para, você não religou a impressão de erro do usuário, o que é um grande problema. Você não pode simplesmente redefinir as opções do usuário dentro abortdepois de chamar stop(), já que o programa parou e seu código de redefinição de opção simplesmente não será executado.

    on.exit()É aqui que entra o R básico . Esta função útil permite que você forneça um bloco arbitrário de código para ser executado após a saída da sua função, mesmo que ela saia devido a um erro não tratado . Podemos, portanto, dizer on.exitpara redefinir as opções do usuário quando saímos da abortfunção, desde que registremos as on.exitinstruções antes de executar stop()o programa.

    Esse mecanismo é essencialmente como rlangele consegue produzir mensagens de erro com formatação personalizada, por meio da função rlang:::signal_abort.

    Também queremos examinar a pilha de chamadas para que possamos informar ao usuário onde abortfoi encontrado, então uma implementação mínima pode ser algo como:

    abort <- function(msg) { 
  sc <- sys.calls()
  lsc <- length(sc)
  if(lsc == 1) header <- "Error:\n"
  if(lsc > 1) header <- paste0("Error in `", deparse(sc[lsc - 1][[1]]), "`:\n")
  old_options <- options(show.error.messages = FALSE)
  on.exit(options(old_options))
  message(header, msg)
  stop(msg)
}

    Testando, obtemos:

    abort("Abort messages print as desired") 
#> Error:
#> Abort messages print as desired

stop("Standard error messages still print normally")
#> Error: Standard error messages still print normally

    E se encontrarmos abortdentro de uma função, podemos ver que a execução foi interrompida e obtemos algumas informações sobre a chamada que levou ao abortseu acionamento:

    test_fun <- function() {
  abort("This is the error")
  cat("This line should not print")
}

test_fun()
#> Error in `test_fun()`:
#> This is the error
    • 3

  2. A resposta de @AllanCamerons já responde minha pergunta de uma forma muito elegante. No entanto, há um problema que continua me incomodando: a função sinaliza uma mensagem e um erro. Depois de estudar o código-fonte de rlang::signal_abort(), descobri que uma mistura de signalCondition()e cat()reflete principalmente o comportamento de rlang::abort():

    abort <- function(msg, call = sys.call(1)) {
  cnd <- errorCondition(msg, call = call)
  signalCondition(cnd)
  msg <- sprintf("Error in %s:\n- %s", deparse(call), msg)
  cat(msg, "\n", file = stderr())
  old_options <- options(show.error.messages = FALSE)
  on.exit(options(old_options))
  stop("")
}

    O que (eu acho) isso faz:

    • signalCondition(cnd)é onde a condição de erro é sinalizada e especifica a mensagem de erro "oficial" (como manipuladores de condições capturadas), mas não aborta a execução.
    • cat(..., file = stderr())imprime em stderr mas não sinaliza uma mensagem.
    • stop("")aborta a execução, mas não sinaliza outro erro (pois isso já foi feito anteriormente) nem imprime uma mensagem de erro (pois ela é suprimida).

    Por que isso é útil:

    • As condições da mensagem não são capturadas por um manipulador de condições.
    > tryCatch(abort("something went wrong"), message = \(e) "message caught!")
# Error in tryCatch(abort("something went wrong"), message = function(e) "message caught!"):
# - something went wrong
    • Mensagens de erro não são impressas quando a condição de erro é capturada por um manipulador de condições.
    > tryCatch(abort("something went wrong"), error = \(e) "error caught!")
# [1] "error caught!"
    • Objetos de condição capturados por manipuladores de condição usam a mensagem de erro não formatada, que pode parecer menos estranha na prática, dependendo do formato aplicado.
    > try(abort("something went wrong"))
# Error : something went wrong
    • 0

relate perguntas