A few decades ago, structured programming was all the rage.
One of the things it advocated was a single return at the end of a routine. That made flow charts look good. Flow charts were also all the rage.
Some programming languages were designed during that era that only supported the single return at the end of a routine idiom.
Professors at colleges around the world were teaching the merits of structured programming, and many developers to this day still strongly abide by the single return at the end of a routine idiom.
Now we have object-oriented programming, and throwing exceptions. Exceptions are an invisible goto, and are another kind of a return. Violating the single return at the end of the routine idiom. Yet the strong adherents to structured programming turn a blind eye to exceptions in object-oriented land, because those are for exceptional situations and not normally happy path flow control. (No one would use exceptions for normal situation flow control, right? Mwa-ha-ha-ha-ha-ha!)
I give a glossy overview of the backstory not to promote single return at the end of a routine idiom. (I don't have strong feelings about it, pro or con.) Rather, to help people understand why many developers abide by that pattern.
A few decades ago, structured programming was all the rage.
One of the things it advocated was a single return at the end of a routine. That made flow charts look good. Flow charts were also all the rage.
Some programming languages were designed during that era that only supported the single return at the end of a routine idiom.
Professors at colleges around the world were teaching the merits of structured programming, and many developers to this day still strongly abide by the single return at the end of a routine idiom.
Now we have object-oriented programming, and throwing exceptions. Exceptions are an invisible goto, and are another kind of a return. Violating the single return at the end of the routine idiom. Yet the strong adherents to structured programming turn a blind eye to exceptions in object-oriented land, because those are for exceptional situations and not normally happy path flow control. (No one would use exceptions for normal situation flow control, right? Mwa-ha-ha-ha-ha-ha!)
I give a glossy overview of the backstory not to promote single return at the end of a routine idiom. (I don't have strong feelings about it, pro or con.) Rather, to help people understand why many developers abide by that pattern.
Joel on Software, regarding exceptions:
Raymond Chen, regarding exceptions:
It is always good to know history. Patterns are here to help us developing. We don't have to follow them blindly. Thank you for sharing!