"catch" wrapper (commit 0ecff30a328993179b757a13830a1a5249839dd8)

[Clemens Lang]

Hi,

----- On 28 Nov, 2016, at 10:05, René J.V. Bertin rjvbertin at gmail.com wrote:

> The new catch command
>> can't simply be aliased in to the slaves like we
>>     normally do for shared commands because it uses uplevel and aliases add
>>     an extra call level.
> 
> Does this mean that every expression in every Portfile or PortGroup that uses
> catch has to be verified and possibly rewritten to handle the extra call level?

No. It only means that we had to use a different method to replace the catch
command in Portfiles.


> I see that the native catch is available as "builtin_catch"; is there any way of
> knowing when the wrapper is required because the caught expression can raise
> signals, i.e. when those Tclx signal handlers can come into action during
> evaluation of an expression and when the can't?

The rule is that you should always use the wrapped version and never use the
builtin version directly. Consider "builtin_catch" a private implementation
detail.

The wrapper is always required, because a user could ^C at any time during the
evaluation of your Portfile, and your Portfile should not try to be intelligent
about how to handle this.


> PS: native_catch would have been a bit less ambiguous than builtin_catch IMHO,
> if it's a command that is not off-limits to us poor mere mortals of course.

It's off-limits, so the name doesn't matter.


-- 
Clemens Lang