Go Card Error Handling

[J. Landman Gay]

In HyperCard 2.2: The Book, the example handler for a "go" to a 
non-existent card checks the result and gracefully handles any failure. 
Presumably it doesn't throw an error so the stack author can manage 
navigation without interrupting the user with a dialog.

The sample handler describes a "statistics" stack where each card has 
baseball stats for a particular year. Not all years are represented. The 
handler checks the result and if the card isn't found, the handler 
answers "Sorry, there are no stats for that year."

So apparently it was done that way on purpose and assumes the stack 
author will handle failed navigation gracefully. In the case of a stack 
that HC can't find, the "go" command puts up a standard file dialog so 
the user can locate it. In the case of a non-existent card in a stack 
that is not open, the result is set to "no such card" and the 
destination stack is brought to the front.

On 6/23/2016 12:33 PM, Mark Waddingham 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!).
>


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com