In "HyperCard: Script Language Guide" the "go" error message result is described in the context of file I/O, that is, finding the stack when there is a "without dialog" clause.
> On Jun 23, 2016, at 11:33 AM, Mark Waddingham <[email protected]> wrote: > > Hi all, > > Whilst investigating a bug this afternoon > (http://quality.livecode.com/show_bug.cgi?id=17873 - which has a moral > attached to it, I'll come back to that) I was reminded that 'go card' seems > to have somewhat inconsistent error handling compared to other commands which > reference objects. > > In pretty much all cases I can think of if a chunk cannot be resolved because > one of its parts does not exist, then a runtime error is thrown. e.g. > > put the name of button "ThisButtonDoesNotExist" > -- throws error "Chunk: no such object" > > copy char 1 to 5 of field 1 of card "ThisCardDoesNotExist" > -- throws error "Chunk: can't find card" > > However, if I do this: > > go card "ThisCardDoesNotExist" > -- no error thrown: the result is "no such card" > > In situations such as this, usually there is an apparent reason for the > difference I can point to - however in this case I struggle to think of one. > 'Going' to a card requires resolving a chunk reference, and by the rules > which are followed everywhere (?) else, and so if that chunk reference does > not resolve an error should be thrown. > > I was just wondering if anyone knew why the behavior of 'go card' is > different from, well, pretty much all other commands acting on chunks... Is > it a HyperCard compatibility thing? An oversight from long ago? Is the > difference actually useful and important in any way? > > I filed an anomaly about it here - > http://quality.livecode.com/show_bug.cgi?id=17901 - as it seems truly > anomalous, however, like everything else, knowing the 'why it is the way it > is' would be helpful to decide whether something should be done about it at > some point, or whether it is something which should always be the way it > currently is. > > Warmest Regards, > > Mark. > > P.S. In regards to the original report which prompted my pondering on 'go > card', then its important to remember (when processing actual formatted text) > that just because something looks like a space, it doesn't mean it is a space > - spaces and non-breaking spaces are very different things (from the point of > view of comparing strings, at least!). > > -- > Mark Waddingham ~ [email protected] ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > _______________________________________________ > use-livecode mailing list > [email protected] > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
