Hugo Kornelis (10/9/2013)
L' Eomot Inversé (10/9/2013)
It would be nice to know what the real reason for excluding those statement is, and whether it has any validity or is just silliness, because if it is just silliness we might be able to persuade MS to allow this very useful error detection and containment construct inside multi-statement functions.
No idea about the official reason, but here's why I don't care.
Allowing TRY CATCH blocks would only effect the types of functions that you probably shouldn't be using anyway,
I guess that is based on the view that the only use for UDFs is in a query.
However, they could also be used in much the same way as stored procedures, and should be just as efficient as stored procedures (but not, unless written as a single statement, as efficient as an inline tabled-valued UDF) and if it wasn't for this restriction they would be quite useful in that respect; if I wanted something to be free of side effects I could write it as a UDF instead of as a stored procedure, or, perhaps more realistic since I trust myself not to write stuff with side effects when I don't intend them, I could instruct a junior programmer to do it as a UDF and not as an SP. In addition, if UDF's were always used in place of SPs whose function is simply to return a result (scalar or rowset) without causing any side effects I would be able to see immediately which program units were available for use when the intention was to use a declarative model of programming for some task, rather than having to look at the code to find out.
However, I recognise that I'm in a minority of people concerned with databases in having the sort of background that makes me take an interest in declarative and fiunctional styles and want to be able to detect easily exactly which bodies of code are side-effect-free and which are not. So even if UDFs were allowed to do error management they probably wouldn't be exploited for being known to be side-effect free, and that (at least until database developers stop thinking in terms of purely state-oriented procedural programming using sets and start thinking instead about functional and declarative programming using sets, which I don't see happening any time soon) means that it wouldn't be worth-while for MS to allow try-catch in functions if it requires significant development to allow an error to transfer control to the catch block instead of exiting the function (which seems to be be the reason why TRY is not allowed in functions, despite the text of the error messages, if the thing timwell found is accurate).
So although you don't care, my background ensures that I do.