org-protocol-check-filename-for-protocol obscures other errors

org-protocol-check-filename-for-protocol obscures other errors

[Adam Porter]

Hi,

I've found that catching errors at this spot in
org-protocol-check-filename-for-protocol (currently line 618 in the
file):

file:~/src/org-mode/lisp/org-protocol.el::(error

Is causing a couple of problems.

1.  Any error in the sub-protocol handler causes the handler to be
called a second time with an old-style link string.  I guess this is
okay if the reason for the error is the handler's not handling new-style
links, but if not, calling it a second time with the other string
doesn't work.

2.  Catching all errors here obscures any error in the sub-protocol
handler.  This makes it very difficult to debug the handler.

For example, in my handler I was calling call-process-region with a
final argument which should have been a string, but because of a bug in
my code the argument was nil, and this caused call-process-region to
give an error.  But the error was caught and replaced with the warning,
and then the handler was called a second time, which, of course, failed
again.  Even using edebug on the handler didn't help, because the error
was still obscured.  I had to take apart the handler and run each
expression manually to get to the real error.  (I tried temporarily
removing the condition-case from
org-protocol-check-filename-for-protocol, but for some reason that
didn't help--I probably did something wrong.)

Could this code be adjusted to help avoid this problem in the future?

Thanks.

Re: org-protocol-check-filename-for-protocol obscures other errors

[Nicolas Goaziou]

Hello,

Adam Porter <adam@alphapapa.net> writes:

> I've found that catching errors at this spot in
> org-protocol-check-filename-for-protocol (currently line 618 in the
> file):
>
> file:~/src/org-mode/lisp/org-protocol.el::(error
>
> Is causing a couple of problems.
>
> 1.  Any error in the sub-protocol handler causes the handler to be
> called a second time with an old-style link string.  I guess this is
> okay if the reason for the error is the handler's not handling new-style
> links, but if not, calling it a second time with the other string
> doesn't work.
>
> 2.  Catching all errors here obscures any error in the sub-protocol
> handler.  This makes it very difficult to debug the handler.
>
> For example, in my handler I was calling call-process-region with a
> final argument which should have been a string, but because of a bug in
> my code the argument was nil, and this caused call-process-region to
> give an error.  But the error was caught and replaced with the warning,
> and then the handler was called a second time, which, of course, failed
> again.  Even using edebug on the handler didn't help, because the error
> was still obscured.  I had to take apart the handler and run each
> expression manually to get to the real error.  (I tried temporarily
> removing the condition-case from
> org-protocol-check-filename-for-protocol, but for some reason that
> didn't help--I probably did something wrong.)
>
> Could this code be adjusted to help avoid this problem in the future?

I tried to improve the situation in maint branch. Please let me know if
it makes your life easier !

Regards,

-- 
Nicolas Goaziou

Re: org-protocol-check-filename-for-protocol obscures other errors

[Adam Porter]

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> I tried to improve the situation in maint branch. Please let me know if
> it makes your life easier !

Looks great, thanks!