sort bug

[Geoff Canyon]

>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 at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>