emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug: Error handling in source blocks.


From: Tim Cross
Subject: Re: bug: Error handling in source blocks.
Date: Wed, 11 Aug 2021 06:30:26 +1000
User-agent: mu4e 1.6.2; emacs 28.0.50

James Powell <powellj@pdx.edu> writes:

>   Error handling is important and hard to get right.  Me, I prefer to
>   treat every warning as an error (-Werror in gcc, "options(warn=2)" in
>   R, etc).  I want the system to grind to a halt at the least sign of
>   trouble.
>
>   When I write some nonsense into a code block as in this example:
>
>   ,----
>   | : This next code block is intended to trigger an error, because that
>   | : variable "fffff838293483" with that attribute/member "x8483848"
>   | : probably does not exist.
>   | :
>   | : #+begin_src R :exports both
>   | : x <- fffff838293483$x8483848
>   | : #+end_src
>   | :
>   | : #+RESULTS:
>   | :
>   | : #+begin_src R :exports both :results table :colnames yes
>   | : require(tidyverse)
>   | : tribble(~a, ~b, 1, 2)
>   | : #+end_src
>   | :
>   | : #+RESULTS:
>   | : | a | b |
>   | : |---+---|
>   | : | 1 | 2 |
>   | : #+end_src
>   `----
>
>
>   which does trigger an error in R
>   ,----
>   | Error: object 'fffff838293483' not found
>   | [traceback follows]
>   `----
>
>
>   and I do org-to-PDF export, I would like the PDF to be not built and
>   loud alarm bells to ring bringing the error to my attention.
>
>   What happens instead: the document builds from org into PDF with no
>   indication that anything went wrong at all, except perhaps minor bits
>   of missing or incorrect text in the PDF file.  The error can easily be
>   buried in the output as more and later source blocks from the same
>   document are evaluated.
>
>   Likewise, in 'sh',
>   ,----
>   | #+begin_src sh :exports results
>   | exit 1
>   | #+end_src
>   `----
>
>
>   Sh exits 1 to indicate an error, so I would like this to ring alarm
>   bells and fail to produce a PDF on org-to-PDF export.
>
>   We might add examples in Java, Python, C++, C along the same lines.
>   All of these should be in a unit test (because error handling is important).
>   There do not seem to be any unit tests that exercise error handling in
>   org-9.4.4.
>
>   Exceptions that are thrown in the block should also at least
>   optionally always and reliably abort the org-to-PDX export and ring
>   alarm bells.
>
>   I would like to see a section in the org manual called "Error handling
>   in source blocks" that discusses the issue.
>
>   I searched for "error handling" at <https://lists.gnu.org/archive>,
>   with no results that are relevant.
>
>   thank you for your time,
>   - JP

Hi James,

I wanted to reply to your message mainly to let you know it hasn't been
ignored. However, I think you have only uncovered a tip of a very large
iceberg and dealing with it will be non-trivial. 

I pretty much agree with most of what you wrote. However, I'm not sure
I'd call this a bug. Rather, I would argue this is a request for a
feature enhancement. For me, a bug is something which does not behave or
work as intended. I'm not sure anyone has really considered a consistent
approach to error handling. It is something which I think would be very
beneficial, but I also think it is something which will be difficult to
achieve consistently across all languages. For example, in an
interpreted language, you could have errors due to problems with the
interpreter, you could have errors in the code or you could have a code
block which legitimately returns an error. Do you always want everything
to halt/stop on all errors? What about a code block which is used by
another code block which returns an error which the calling code block
actually uses to control it's behaviour? Then we have warnings. You want
warnings to act like errors, but I don't. For me, warnings and errors
have different semantics. I see a warning as something which alerts me
to something which might be a problem, but has not caused an error.
Provided you understand the warning, you should be free to ignore it. 

To me, babel is something which has evolved inside org mode rather than
something which has been designed and implemented. Based on a fairly
simple idea initially, it has grown to be powerful, but with some
confusing semantics, complex options, language inconsistencies and
missing features. This is not a criticism of the work done by
maintainers and contributors. Rather, it is simply the consequence of a
system which has evolved to meet user requirements.

I think a consistent approach to error handling in source blocks would
be an excellent addition. However, I think we also need to clarify the
syntax and semantics around code blocks. I still find the whole
semantics surrounding return values from code blocks somewhat confusing
- is what is written to stdout the return value or is it what the block
of code returns? What is the precise relationship between stdout and
stderr and results? What about differences between languages like a bash
script where both the return value and the output are important compared to a
language like clojure or common lisp where the return value is really
what matters or languages which don't return anything unless you
explicitly tell it to.

There was some work done with respect to return values only a few months
back and it has improved things. However, how this would all relate to
error handling is unclear. How will the different result options
interact with error handling? Is it sufficient to just halt on errors or
will this cause problems for some users? Do we need to distinguish
between different types of errors? How complex does an error handling
approach need to be? Can we really sustain yet more header arguments?
Are we yet in a position to seriously look at error handling or do we
need to improve consistency across languages and code blocks?

I apologise this is more question than answer. To be honest, while I
agree with your sentiments, I really am not sure what the right
answer/approach is. I do think it is an important question and I hope
others in the community will be prepared to assist, especially those
with more familiarity with the whole bable infrastructure. I think a lot
more discussion on this topic is required and hope you will be able to
participate if/when it occurs. 

regards,

Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]