What was actually happening in the above case was that they were simply starting a named transaction that happened to have the same name as their stored procedure, not doing anything inside that transaction, and then committing. The code was equivalent to the following, which makes it much more obvious what is going on:
BEGIN TRANSACTION ProcedureName; COMMIT TRANSACTION;
Which means their stored procedure wasn't even being called - so of course it couldn't possibly have generated any errors. This would have been caught long earlier had they written it the "right" way in the first place. Statement terminators and/or the schema prefix would have ensured that the code wasn't falsely accused of succeeding:
BEGIN TRANSACTION; EXEC dbo.ProcedureName; COMMIT TRANSACTION;
So, once again, I strongly, strongly, strongly recommend you get in the habit of accurately referencing all objects with their schema in all scenarios, and properly terminating all relevant statements with semi-colons.
As an aside, though, note that not all statements are eligible for termination; for example, I was surprised when I learned that three out of the four statements in the
TRY/CATCH construct can have semi-colons, but one of them can't:
BEGIN TRY; SELECT 1/0; END TRY -- <-- *** not valid here *** BEGIN CATCH; PRINT 'ruh roh'; END CATCH;
If you put a semi-colon after
END TRY, you'll get not one error, but two:
Msg 102, Level 15, State 1, Line 3 Incorrect syntax near ';'. Msg 102, Level 15, State 1, Line 7 Incorrect syntax near 'CATCH'.
The reason, while not intuitive, is that
TRY/CATCH is one statement "block," and there is no functional reason to terminate
END TRY - since no statement is valid between
END TRY and
BEGIN CATCH. But this is an exception that shouldn't discourage you from trying.