Hi, ----- On 28 Nov, 2016, at 10:05, René J.V. Bertin [email protected] 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
