On 18.11.2015 09:56, Josef Reidinger wrote:
And to be honest it can happen in any code in any language ( just depending how often it can happen ).
Wrong. Any halfway decent parser will realize that in one case you do return something from your function, and in another you don't. That's what happened here. Better yet, if you have to DECLARE your stuff (functions, variables), you are making a commitment (or a contract, however you want to name this) what you are going to do with that thing and what you don't. And the parser (no matter if it's an interpreter or a compiler) can catch those problems.
E.g. in ycp one nil can result in cascade of nils.
I really wouldn't call YCP, of all things, a shining example of good behaviour when it comes to this. Yet, even it had (after years of painful debugging) static type checking that at least did some minimal amount of plausibility checks.
What is ruby philosophy how to solve it? Tests. Do not trust code that is not tested. Of course some tools can detect some misusage, but only good tests can prove that code really works.
Tests are good, but they have limits. In particular, when your number of code paths is too high, the possible permutations just explode. That's why achieving good test coverage is so difficult. Ruby (and the tools in its ecosystem like Rubocop) try to make you believe that you can easily handle this by dumbing down functions enough so they become trivial. Well, that would be good - if only there were a practical way to go through each code path at least once (better yet, with some permutations of your data set / variables to test fringe cases in the less frequently taken code paths, too). But as seen in this example, this is often not practical. If your code depends on the status of things beyond your immediate control, you'd have to mock all that. In this particular case, who would have foreseen that a seemingly unrelated scenario like having a RAID on the previous installation might lead to such a crash? Sure, better test coverage might have caught this. But it would have been even simpler (very much simpler!) to have the parser throw an error if the code is inconsistent - like not returning a value in this case if in the other case it does. And to cut the reply that immediately comes to mind short: If in some pathological case I want the code to return 'nil', I can explicitly make it return 'nil'. IMHO there is no real excuse for the Ruby parser to behave this dumb. They just became collateral damage of their own "anything goes" philosophy. CU -- Stefan Hundhammer <shundhammer@suse.de> YaST Developer SUSE Linux GmbH GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org