I'll indicate this question as answered - well I'm not happy with the answer so far, so I have just added enhancement request no. 0000003730 to add an NO-ERROR option to the FIND-FIRST and similar methods.
Please feel free to vote :-)
Thanks everybody for the discussion so far!
Why don't you create a FindFirst(...) user defined function that handles the no-error. Seems like a reasonable workaround, pass in a buffer handle and an expression string and do the assign-no-error in the function...
As you've said, that's just a workaround, causing an extra function call on the stack. In a AFTER-ROW-FILL event handler of a Prodataset Buffer that might be executed pretty often.
If you use OERA, AutoEdge or similar type service there are several layers with many procedure and function calls and in my case I don't see any performance problems. I also have a number of function calls in an afterowfill with no issues. Ensure the function is supered.
While I agree, Mike, that this is a reasonable enhancement to get on the list and one that doesn't seem hard, I think that you might consider being glad that there is a fairly reasonable workaround. If you create the function, the code should be fairly clean in line and probably not hard to refactor if you get your wish. I would start there and, if it turns out that you do have a performance issue in certain places, then do an in-line version in those cases. Yes, there will still be a nominal performance hit from the catch, but I would wait for it to bite you before I reached for the muzzle.
Consulting in Model-Based Development, Transformation, and Object-Oriented Best Practice http://www.cintegrity.com
I've already written, that I accept the workaround and I've used it before - either inline or using a user defined function (in a super or elsewhere). And I'm also sure, that the runtime overhead is absolutely minimal. But in the end it's still just a workaround and requires extra coding.
But my initial question was, if others dislike the "functionality" of the messages that (at least in 10.1B) don't raise an error. I've only received a few answers, so I accept the fact, that this will not become an item very high on the priority list.
No, there I would agree with you. Untrappable messages is an ugly feature and the more we can do to trap them, handle them gracefully, and make it easy to do so, the better.