On 26.01.2018 03:26, Tanu Kaskinen wrote: > On Thu, 2018-01-25 at 07:38 +0100, Georg Chini wrote: >> On 25.01.2018 00:26, Tanu Kaskinen wrote: >>> On Wed, 2018-01-24 at 22:01 +0100, Georg Chini wrote: >>>> On 24.01.2018 02:10, Tanu Kaskinen wrote: >>>>> How does validating the brace correctness prevent some values being >>>>> used before all values have been parsed? You're only enforcing brace >>>>> correctness, but if you have a list of doubles, any of the double >>>>> values can be invalid. Nothing is preventing the application from using >>>>> the first values of the list before noticing that a value later in the >>>>> list is invalid. >>>>> >>>>> I didn't claim that my approach was any better in this regard, you were >>>>> just making impossible-sounding claims about the benefits of your >>>>> approach. >>>> I can only repeat myself: My example above shows how this >>>> helps detecting errors before any values are used at all. The >>>> point is, that the consistency check is done before the values >>>> are parsed. This means when pa_split_message_response() >>>> returns a list, the whole list is already checked for consistency >>>> (with the exception of the outer, implicit list). This does neither >>>> prevent later lists from having issues nor does it help against >>>> wrong list values, but at least you should never hit a parse >>>> error within a list. I think it is a big benefit to know in advance >>>> that a list is at least consistent. >>> I just don't see the big benefit. You have to do error checking for the >>> individual values in any case. The benefit of having the list >>> formatting check early is that reading the individual values can't fail >>> due to list formatting errors, but since there are other error cases, >>> the code complexity for reading a value is exactly the same as without >>> any early list formatting checks (assuming that the application doesn't >>> care about the exact failure reason). >> Strange that you don't see the benefit. In my example, if the y1 >> y2 are very high but still acceptable volume values, not catching >> the parse error in advance could even lead to damage of >> hardware or ears. > So this "big benefit" is only for the cases where an application uses > some parameter values before the whole message has been parsed. That's > always a bad idea, so nobody should be doing that, and therefore the > benefit seems very small to me. > I already said it is only a benefit if you use the values before the whole sub-list has been parsed. There are many situations where parsing the whole message before using any value seems impractical. Take the list-handlers message. If you had to read the whole list before using the elements, it would mean you have to set up some dynamic array to store the values.
