It seems the error/bug is related to the error being in the last value. If you were to change the bug report to sort on the field itself, then the sort is performed but the answer does not execute. If you clicked the button again, then the answer does show. If you revert to the saved stack and add a valid value after the bad one, the answer works as expected with the bad value being first.
Brian Milby br...@milby7.com > On Sep 6, 2023, at 10:31 PM, Geoff Canyon via use-livecode > <use-livecode@lists.runrev.com> wrote: > > From the original email: > > If the function myVal encounters a run-time error (in the example if one of > the items is not a number) the sort command fails silently: the script > exits at that code line and the user is unaware that the sort (and the rest > of the handler) were not executed. > > > To be clear: the above is NOT what I'm seeing. Mark W says in the bug > report: > > The 'sort ... by ...' command has always allowed the by expression to be > fault tolerant - if evaluating it generates a runtime error then the sort > key for that element is just taken to be the original element. > > And that is what I'm seeing. For example, this code does not exit -- it > displays the answer dialog as if nothing out of the ordinary has happened: > > on mouseUp > sort lines of fld 1 numeric by sortVal(each) > answer "done" > end mouseUp > > function sortVal S > return item 2 of S + item 3 of S > end sortVal > > It seems to be sorting as Mark described: when the function fails, the > whole line is used for the sort. And that "fallback to the whole value > needs better documentation, and could lead to some truly dismal debugging > situations, but it doesn't seem like a bug to me. > > The original report, if I were able to replicate it, would clearly be a bug. > >> On Sat, Sep 2, 2023 at 8:19 PM neville smythe via use-livecode < >> use-livecode@lists.runrev.com> wrote: >> >> Geoff Canyon wrote (after a bravura display of how many different >> ways there are to do things in LC!) : >> >> And the function sort also sorts based on a negative infinity value >> for >> >> errors. I'm not sure I'd consider that a bug. >> >> Hmm. I would. The sortKey function should tolerate any sort of >> run-time error? But anyway that's not the issue. The bug I see is that >> the sort command exits its containing handler - actually I presume the >> sortKey function exits to top - without throwing an error, so nothing >> beyond that line is executed. This creates a very difficult problem >> to track down, since the code appears to be executing correctly, until >> something falls over or a file gets corrupted much later because some >> stuff never happened. >> >> Of course one should always validate data, particularly if it's not >> your own data. In this case it was my own data! Moreover I had thought >> I had checked for invalid cases, just hadn't checked all possible >> kinds of invalid data (the sortKey was rather more complicated than >> the one I used for illustration). >> >> Neville >> >> ------------------------- >> Email sent using Optus Webmail >> _______________________________________________ >> use-livecode mailing list >> use-livecode@lists.runrev.com >> Please visit this url to subscribe, unsubscribe and manage your >> subscription preferences: >> http://lists.runrev.com/mailman/listinfo/use-livecode >> > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
