Go Card Error Handling
dsc at swcp.com
Thu Jun 23 19:56:21 CEST 2016
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 <mark at livecode.com> 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,
> 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 ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
More information about the use-livecode