#2575 [selection handle] errors are silently discarded

[Andy Goth]

If the command registered by [selection handle] returns an error, the error is silently discarded. The background error handler does not see it.

[Donal K. Fellows]

Fixed in HEAD; errors now go to bgerror mechanism. Note that if someone was relying on the old behavior, they may be impacted by this. (Their code was always dodgy, but even so...)

[Jan Nijtmans]

test-case select-5.15, which was written to test for bug-2441988,
is failing in head, since ages. Does that mean that
bug-2441988 is re-introduced, or is something else
going on, like interactioon with [interp bgerror]?

==== select-5.15 Tk_GetSelection procedure FAILED
==== Contents of test case:

proc ::bgerror msg {lappend ::bgerrors $msg}
selection handle .f1 ERROR errHandler
list [catch {selection get ERROR} msg] $msg [update] {*}$::bgerrors

---- Result was:
1 {PRIMARY selection doesn't exist or form "ERROR" not defined} {}
---- Result should have been (exact matching):
1 {PRIMARY selection doesn't exist or form "ERROR" not defined} {} {selection handler aborted}
==== select-5.15 FAILED

[Jan Nijtmans]

Hey, if I change the syntax to:
selection handle -type ERROR .f1 errHandler
then the test passes.

committed to trunk now. At least this shows that
errors are still catched using the new "select"
syntax. Apparently not with the old syntax.
But it never did - anyway - so this is not
a regression.

Donal, agreed? I think this one can be closed.

[Donal K. Fellows]

Confirmed the fix.