On Nov 11, 2013 6:10 PM, "Vlad Irnov" <vlad.ir...@gmail.com> wrote:
>
> On 11/4/13, ZyX <zyx....@gmail.com> wrote:
> >> This means in Vim 7.4 Vim script stops after a Vim error occurs in
> >> Python code. This seems very wrong to me. Vim script writers are used
> >> to the fact that VimL code execution does not stop after an error
> >> unless there is a try/catch or when function has "abort" argument.
> >
> > Code that relies on this is broken. No matter how is some functionality
used
> > it *can* be put inside try/catch by the user*. I already got a few
“nice” to
> > debug bugs when was assuming `echoerr` is not breaking execution flaw
(note:
> > without any traces of python). Now they will be easier to fix: now when
I
> > see `echoerr` I say I must remove it.
> >
> > For echoing errors from python there is `sys.stderr`.
> >
> > Besides, any error shown to user indicates a bug.
> >
> > *:
> >
> > - Any command and function can be naturally put inside :try/catch in a
> > script.
> > - Any mapping can be called with :normal that can be put inside
:try/catch.
> > - Any autocommand can be called either directly with :doau inside
:try/catch
> > or by putting commands that invoke autocommand inside :try/catch (i.e.
:e
> > for BufRead*).
> >
> > There is no way write code that will never stop execution on error
without
> > using :silent! or :try/catch catching the error on your own. Hence any
error
> > must be considered to break execution. Any code that considers error not
> > breaking execution is broken.
>
> All this is true in theory. In practice, nobody ever puts the entire
> Vim script plugin inside try/finally/endtry. The simplest case:
You sure? There is SourceCmd that allows *any* script sourced after this
event was defined to be put into :try. If you hook it you can collect some
stats, determine what did this script define (useful for more bulletproof
script autoloading; there exist some plugins which do script source parsing
for this purpose) and like this. It is natural to put actual sourcing into
:try and after-source processing in :finally.
> let s:keepcpo= &cpo
> set cpo&vim
> echo 1
> let a = bogus
> echo 2
> python a = bogus
> echo 3
> python vim.command("let a=bogus")
> " execution stops here
> echo 4
> let &cpo= s:keepcpo
> unlet s:keepcpo
>
> When such script is sourced, execution does not stop after a Vim
> script error or a regular Python error. Why should it stop after a
> Python vim.error error? This is an inconsistent behavior of Vim error
> handling that is bound to cause confusion.
If there is unhandled error script is left in inconsistent state: some
necessary initialization was done correctly and some was not. Ignoring it
does not do any good. In python you can no longer ignore it.
What you see is not consistent with VimL. But it is more natural in python
world. There are warnings in python that may or may not be exceptions. But
errors like "List index out of range" for python lists are non-ignorable
IndexErrors. As 99% of vim errors would be expected to be exceptions if you
were writing python and not warnings I use exceptions always.
Besides I have no idea how to prevent vim from printing messages and yet
transform them into warnings and exceptions with appropriate text without
hooking deeply into non-if_py* files. Using exceptions required me AFAIR no
or little changes outside of if_py*. If I was thinking warnings are good
for this job I would not hesitate. But I was and am not.
> Regards,
> Vlad
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
"vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
