James Powell <powe...@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