There is one thing that Aaron Bertrand won't get mad at me for doing and that's creating an infinite loop with a WHILE (1=1) pattern. He wrote about this recently in a tip, noting that it's easy to create an infinite loop with code like this, something that never ends well.

I have purposefully written infinite loops in the past. A long, long time ago Radio Shack would put out TRS-80s on display, and a few of us would type a quick BASIC program to perform some math work on the screen over and over with an infinite loop. It crashed at some point with an overflow, but for a period of time, it would look neat on the screen. Less neat to the salespeople who weren't always sure how to stop it and demonstrate something else without resetting the machine.

I've also created infinite loops by accident at various jobs. Those experiences have left me a little concerned about any loop that doesn't have a defined time to end. I usually use a technique similar to Aaron, ensuring the loop ends. If needed, I add a call that can repeat the entire process if more data needs to be updated after the current loop ends.

There are plenty of people who spotted the error in the code and think they wouldn't create that problem in their looping code. However, I think few of us work alone on code for an employer, across time. Often someone else comes in to refactor or "improve" our code. The next person that adjusts this loop might join back to the main table and not realize they are creating an infinite loop. You'd hope they'd test this and find the problem, but I continue to see lots of "little fixes" deployed without being tested.

This is one reason I want a DevOps style process for database code, complete with automated testing. If you write a piece of code, you are responsible for including a test in the pull request so that the CI system can verify your code passes the test. This isn't a perfect system and it might not prevent all bugs, but at least a test will exist and someone can then check both the code and test and perhaps use the issue as a teaching moment.

We try and avoid loops in SQL Server, but that isn't always possible. As with most techniques in programming, we should strive to learn the best ways to use them, know the weaknesses, and avoid building code that has major flaws now. Maybe we also ought to add that we should ensure our code doesn't lead less experienced developers in the future to make simple mistakes. I'd say the 1=1 looping code does this, and I agree with Aaron; it should be avoided.