On 22/07/09 03:36, Ben Fritz wrote:
>
>
>
> On Jul 21, 5:54 pm, Matt Wozniski<m...@drexel.edu>  wrote:
>> That's exactly what raising an exception does.  When you get an
>> exception, why are you printing out a message about that exception,
>> and then ignoring that it ever happened?  Why not just :throw
>> something in s:ProjGetInfo() and :catch it in the caller?
>>
>
> When I was writing programs for school in Java (seems like forever
> ago), I remember that not being careful with what you placed inside
> try...catch blocks, you ended up eating memory REALLY fast. I think
> that had something to do with Java trying to discard/restore pretty
> much everything within the try or something like that if it failed.
>
> It looks like Vim's implementation is just a sort of instant return-
> through-all-callers, it doesn't try to undo anything. Are there any
> side effects of a try...catch in Vim, performance related or
> otherwise, that one should be aware of?

In Vim, IIUC undoing what a try block did is the user's responsibility, 
by means of the ":finally" clause, which is run even if the try...endtry 
is in a function and there is a ":return" anywhere between ":try" and 
"finally". The general structure of a (full) Vim try block is as follows:

        :try
                " first, save whatever it is that we must later restore
                " do something, possibly raising exception(s)
        :catch /E123/
                " what should we do if exception E123 is triggered
        :catch /E456/
                " if exception E456 is triggered
        :catch
                " if anything we haven't yet caught is triggered
        :finally
                " restore everything to a known state
                " e.g. from what we saved at the top of the :try
        :endtry

The ":finally" is optional, and there may be any number of ":catch" 
clauses. The catch-all clause, if present, should of course be the last 
of them.

<rant>
The one thing missing from Vim's documentation is the text of mmmmost 
exceptions. E.g. ":help E224" tells me that E224 and E225 are about 
buffer-local mappings, but what can I know exactly what they are for, 
and what is the difference between them as long as they don't happen to 
me? I guess the only solution is to run ":cscope find e E224" on the Vim 
source, it tells me:

(1 of 1) <<<unknown>>> ^I^I^IEMSG2(_("E224: global abbreviation already 
exists for %s"),

then hitting the spacebar shows E225 a few lines lower, with "mapping" 
instead of "abbreviation". But can't I sensibly write try blocks without 
a Vim with +cscope, the Vim source at hand, and a cscope.out built on it?
</rant>
Oh well... I suppose Bram has better things to do, and that if I really 
wanted, I could (now that I've found it) document it myself and submit a 
help patch or even a new helpfile. Only there are undreds of them, so 
I'd better automate it somehow... maybe save "somewhere" the QF lists 
generated by cscope (for EMSG, EMSG2, EMSG3, EMSGN, EMSGU, or maybe just 
one list, using EMSG as an egrep pattern) and then reprocess that...

>
> Additionally, what on earth does :echoerr do in relation to all this?
>> From my trial-and-error above, it DOESN'T seem to exit a function,
> even if defined with the "abort" keyword. Neither of these work as I
> expect (i.e. abcd and defg both get the value 123 instead of 0):
>
> function AbErr() abort
>    let g:abcd=0
>    echoerr 'fooblarg'
>    let g:abcd=123
> endfu
>
> fun NoAbErr()
>    let g:defg=0
>    echoerr 'blargfoo'
>    let g:defg=123
> endfu
>
> Does echoerr need to be in a try...catch to be useful in a situation
> like this?

I confess I haven't yet used try blocks much. They are a relative 
novelty (6.2, according to version6.txt), and if I wanted to keep my 
scripts and vimrc version-6-1-compatible, I could use :echoerr but not 
:try:throw:catch:finally:endtry. (That was not the only reason: another 
was that I didn't really understand all those new ex-commands, they came 
from beyond my experience).

As for "abort" in a function definition, I cannot see where it was 
introduced, but it was earlier than 6.0.252, see version6.txt lines 
5365 sqq., so even if "user-thrown exceptions" didn't exist, of course 
"user errors" and "vim errors" (i.e. Vim exceptions) did.

That patch 6.0.252 gives me an idea though: if you put ":if 1" and 
"endif", or failing that "let true = 1 | if true" and ":endif", around 
your ":echoerr", does it make a difference? If it does, then that bugfix 
has come unstuck.


Best regards,
Tony.
-- 
Arithmetic is being able to count up to twenty without taking off your
shoes.
                -- Mickey Mouse

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_use" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply via email to