Re: [Babel] Handling of errors when using Ledger

From: "Sébastien Vauban" <wxhgmqzgwmuf-geNee64TY+gS+FvcfC7Uqw@public.gmane.org>
To: emacs-orgmode-mXXj517/zsQ@public.gmane.org
Subject: Re: [Babel] Handling of errors when using Ledger
Date: Tue, 12 Oct 2010 21:58:46 +0200	[thread overview]
Message-ID: <807hhnfaix.fsf@mundaneum.com> (raw)
In-Reply-To: 87sk0inmys.fsf@stats.ox.ac.uk

Hi Dan,

Dan Davison wrote:
> Sébastien Vauban writes:
> [...]
>> Let's imagine I thought (which was the case at some point) I needed to
>> enclose the parameters between quotes:
>>
>> #+srcname: quoted-params
>> #+begin_src ledger :cmdline "reg unknown" :noweb yes :session
>> <<data>>
>> #+end_src
>>
>> #+results: quoted-params
>>
>> Nothing is returned. In fact, I would expect an error to be thrown [...] I
>> don't know if this is a common problem (to Org-Babel) or only to the Ledger
>> part of it, but I think *we* should somehow improve the handling of errors.
>
> Babel has a standard mechanism for evaluating shell commands and displaying
> errors if any. It is the function `org-babel-eval' in ob-eval.el. The
> problem is that ob-ledger is not using this mechanism. Would you be
> interested in fixing this? Basically what is required is to re-implement
> `org-babel-execute:ledger' using `org-babel-eval'. (There are plenty of
> examples in the other langauges to follow.) Please don't worry if you are
> too busy though.

I'd be interested to try and fix it. I am busy, yes: I am just recovering 3
days of lost time due to my 5 years old PC which crashed on Friday morning. I
now temporarily am on a Windows; but I've had to tweak my Emacs and Gnus a
bit, to recover all the backups done through Unison, and experience all the
problems due to differences in filenames (characters allowed, case
insensitiveness, etc.). Apart from that, we're rebuilding my house, and that
demands a lot of time from me. So, yes, time is a scarce resource, but I'm
sure everybody can say so.

So, I'd propose to fight for being the first one to fix that... And let's see
who will win... ;-)

>> - Maybe displaying a =#+results-err= block which would be what's shown on
>>   =/dev/stderr=, when not void?
>
> I've vaguely wondered about this sort of thing in the past. The thing is
> that that's getting close to the idea of proper exception handling in
> Org-babel. That would certainly be interesting, and I'm sure we would
> welcome well thought-through proposals on the topic.

Quite sad nobody else reacts on this.

> It would need to deal with errors occurring in a block anywhere in the `call
> tree' (e.g. what happens when block A is evaluated and A references blocks B
> and C, and B references D and an error occurs in D)

I don't this we need to go in such a complicated path. After all, if I launch
a script with calls to external commands, I only will see that my parent
script has gotten an error (if checked, even). I never will see exactly which
subcommand can have failed (or only through side-effects: messages with a
clear indication of which program is outputting something on the console).

Plus, I could use D in both A and K. Maybe D succeeds when called from K and
not when called from A. So, when getting an error, I think it is sufficient to
see it associated to the parent block. It's inside it that the error occurs,
after all.

>> - And having a way to display the error code would be a plus.
>
> That will happen automatically when ledger is converted to use
> `org-babel-eval'.

OK. Thanks for your explanations.

Best regards,
  Seb

PS- BTW, I had a very bad habit of letting the important mails as "unread".
Now that I've crashed my PC, I've lost all my mail marks as well... Should I
have used links from Gnus to the important mails...

-- 
Sébastien Vauban

_______________________________________________
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode-mXXj517/zsQ@public.gmane.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode