On Dec 25, 2009, at 1:23 PM, Fredrik Olofsson wrote:
If n_set is doing something other than \gate, 0 and it's operating on a node that no longer exists, then it's a genuine error that the user should be aware of. Suppressing it just because the error occurred for n_set would be wrong. The idea of the current implementation is that the client knows whether it is or isn't appropriate to suppress errors for a given command. The other issue is automatic bundling. You might open up a bundle with s.makeBundle, then call a method that itself uses makeBundle. That inner method should be able to suppress errors within its own scope without interfering with error suppression outside. If you had: s.makeBundle(nil, { s.sendMsg(\error, 0); // this method also does /error, 0 and closes with /error, 1 someObject.callSomeMethodThatUsesMakeBundle(...); // NOTE: x might have stopped on the server by now s.sendMsg(\n_set, x.nodeID, \arg, 1); s.sendMsg(\error, 1); }) ... the intent is still to suppress the possible error on the n_set following the method call -- but that doesn't work because the method re-enabled errors before returning! That's why there's a local option, which uses a counter to know how many "levels" of error suppression are in force within the bundle. I don't disagree with you that it would be simpler to have one option you can set globally that would apply only to releases and n_free's -- it's a special case, albeit a common one. But it doesn't cover all the bases, where the current implementation does. hjh : H. James Harkins .::!:.:.......:.::........:..!.::.::...:..:...:.:.:.:..: "Come said the Muse, Sing me a song no poet has yet chanted, Sing me the universal." -- Whitman |