1 -- There were mentions to use language supported exception handing, but a) not all languages have them or the coder may not know how to use them properly, b) exception handling may introduce too much overhead for the given scenario (just like there are cases where it could to the contrary improve performance).
2 -- The pattern may slow run-time performance, but it may improve it. First, in some languages, you can get compilers to compile the else statement similar to the pattern or vice-versa; however, it does on first sight appear that pattern may slow things down, so a compiler may not do it and it may not remove it either. And not all language environments have compilers. This means there are cases where only by avoiding that pattern (or putting it in by hand) could you improve performance. Let's see for a moment some reasons why the pattern (without else) could improve performance. A: For interpretive scenarios, cutting back on the number of language tokens, all else being equal, would shave time off the clock. B: For various reasons, there are many cpus that perform worse generally the more branching that exists in the machine instructions. The reason is that oftentimes the pipelines have to be flushed when branches are taken. There are predictive branching algorithms embedded inside the cpu. In some cases these could even have a particular branch improve performance, but generally you want to cut back on the number of branches you have in tight loops as a way to increase performance (and the pattern above fulfills that requirement). Sometimes cutting out branches can be had for free, but, as with this pattern, you can incur a cost, such as extra times setting the variable. However, if the extra writes happen infrequently enough, those costs could be overcome by the decrease in branches. Generally, though, you leave that kind of testing until the end. Unless you anticipate otherwise for a given case, that pattern is more likely than not to worsen performance or more likely just have no practical performance effect one way or the other.
3 -- Code readability: It could be cleaner to apply the pattern or not. It depends on the specific case. As was stated in the question, it does appear to cut back on the amount of code. That and having one fewer indentation layer could make a particular section of code look more organized and easier to follow.
4 -- More correct program: As was stated in one of the suggested answers, you may prefer to find bugs as early as possible in the design stages; however, not all programming tasks have the time in the world. Under times stresses, sometimes programming with extra layers of protection can solve the needed problem quickest with fewest problems. The greater chance of introducing or hiding hard-to-detect bugs might just be deemed less important at the moment that avoiding the negative effects of other bugs. In the given case, making sure "age" is set in this section of the code might be very important and by setting it early and in a single place, you could avoid potential future missteps during the addition of extra or longer branches which fail in some part to guarantee "age" is set.
5 -- Some of the complaints were against assumptions made about the code used in the question (what does "age" represent, what is the average case, etc), but at a more fundamental level, the question was about a general practice so those complaints are not complaints against the pattern.
6 -- For code you are writing for your own use or where you are the only one managing the code, what suits you best is possibly just what might be best, when we consider your overall productivity.
7 -- As we move into a world where robots and computers become more adept than humans at creative tasks and pose an increasing threat of one day enslaving humans, code written that simply fails to follow patterns or to use the features of a language to clarify intent may end up being a key defense for humans. I suggest as cheap insurance that some of this style of code be sprinkled here and there. For those times, I would follow the pattern for some of the code and not follow it in other places. [This may also come in handy if you fear being displaced in your job, but it may backfire. You have been warned.]
There were mentions to use language supported exception handing, but a) not all languages have them or the coder may not know how to use them properly, b) exception handling may introduce too much overhead for the given scenario (just like there are cases where it could to the contrary improve performance).
The pattern may slow run-time performance, but it may improve it. First, in some languages, you can get compilers to compile the else statement similar to the pattern or vice-versa; however, it does on first sight appear that pattern may slow things down, so a compiler may not do it and it may not remove it either. And not all language environments have compilers. This means there are cases where only by avoiding that pattern (or putting it in by hand) could you improve performance. Let's see for a moment some reasons why the pattern (without else) could improve performance. A: For interpretive scenarios, cutting back on the number of language tokens, all else being equal, would shave time off the clock. B: For various reasons, there are many cpus that perform worse generally the more branching that exists in the machine instructions. The reason is that oftentimes the pipelines have to be flushed when branches are taken. There are predictive branching algorithms embedded inside the cpu. In some cases these could even have a particular branch improve performance, but generally you want to cut back on the number of branches you have in tight loops as a way to increase performance (and the pattern above fulfills that requirement). Sometimes cutting out branches can be had for free, but, as with this pattern, you can incur a cost, such as extra times setting the variable. However, if the extra writes happen infrequently enough, those costs could be overcome by the decrease in branches. Generally, though, you leave that kind of testing until the end. Unless you anticipate otherwise for a given case, that pattern is more likely than not to worsen performance or more likely just have no practical performance effect one way or the other.
Code readability: It could be cleaner to apply the pattern or not. It depends on the specific case. As was stated in the question, it does appear to cut back on the amount of code. That and having one fewer indentation layer could make a particular section of code look more organized and easier to follow.
More correct program: As was stated in one of the suggested answers, you may prefer to find bugs as early as possible in the design stages; however, not all programming tasks have the time in the world. Under times stresses, sometimes programming with extra layers of protection can solve the needed problem quickest with fewest problems. The greater chance of introducing or hiding hard-to-detect bugs might just be deemed less important at the moment that avoiding the negative effects of other bugs. In the given case, making sure "age" is set in this section of the code might be very important and by setting it early and in a single place, you could avoid potential future missteps during the addition of extra or longer branches which fail in some part to guarantee "age" is set.
Some of the complaints were against assumptions made about the code used in the question (what does "age" represent, what is the average case, etc), but at a more fundamental level, the question was about a general practice so those complaints are not complaints against the pattern.
For code you are writing for your own use or where you are the only one managing the code, what suits you best is possibly just what might be best, when we consider your overall productivity.
As we move into a world where robots and computers become more adept than humans at creative tasks and pose an increasing threat of one day enslaving humans, code written that simply fails to follow patterns or to use the features of a language to clarify intent may end up being a key defense for humans. I suggest as cheap insurance that some of this style of code be sprinkled here and there. For those times, I would follow the pattern for some of the code and not follow it in other places. [This may also come in handy if you fear being displaced in your job, but it may backfire. You have been warned.]
