Go Card Error Handling

[Mark Waddingham]

Thanks Dar and Jacque,

That puts it nicely in context. I'd class this behavior, then, as being 
for 'HyperCard compatibility'.

LiveCode does have a slightly different model from HyperCard though, 
which is why it is perhaps a behavior which should be reviewed at some 
point. Indeed, it actually suggests there are a few other places where 
the error behavior for stacks and cards aren't quite right.

For example, the engine will try to load a stack from disk if a 
reference 'stack "mystack"' isn't in memory - in this case *this* is 
file I/O and such should probably set the result rather than throw an 
error.

When the engine does have a stack in memory, going to a card cannot fail 
due to file I/O (as all objects in a stack are in memory all the time) 
and thus a non-existant card should throw an error. Indeed, you can 
check whether a card exists before accessing it by checking 'the 
cardNames'.

Indeed, this does suggest that *perhaps* the fact that you can do:

    go stack <named_of_stack_in_memory>

Or

    go stack <stack filename>

Suggests that these are two distinct operations and a 'cleaner' model 
would be perhaps to have:

    load stack <stack filename>

To load a stack from disk which, as it involves file I/O, should set the 
result.

And, furthermore, make:

    go stack <name_of_stack>

Only succeed if the named stack is in memory, if it is not then it 
should throw an error.

I'm minded to think here that there is actually a nice separation here. 
In any applications there are stackfiles which can be considered to be 
an intrinsic part of the application, and then all other stackfiles. The 
former will typically have named references somewhere (usually in the 
stackfiles property of another stack), or be included in the description 
of what the application consists of (i.e. the stackfiles which are 
included with a standalone).

The distinction here is between stackfiles for which their non-existence 
should be considered an application failure (just as if a dynamic 
library is not present for a native app, the app will usually not work) 
and stackfiles which the application manipulates (like any other data 
file).

 From an error handling point of view, these present two entirely 
different cases.

For operations which you should always expect to succeed *or* can 
guarantee will succeed by a preceding check in code, the correct error 
approach is to throw.

For operations which could fail and you cannot 'precheck' for failure, 
the correct error approach is to set the result.

To put it slightly more abstractly:

An operation should throw an error for all errors which occur as a 
result of 'system failure' (for some definition of system) which the 
application has done all it can to ensure it cannot happen. In this 
case, if you include a set of stackfiles in your standalone application, 
and one of them fails to load then you can reasonably take this to be an 
'exceptional' circumstance - the problem will be due to something you 
(as a programmer) can in no-way control. (For example, if one of the 
stackfiles on disk is corrupted).

An operation should set the result for all errors which occur which 
cannot be checked for beforehand - typically this will be because there 
is a time-of-check to time-of-use problem. In this case, if you have a 
stackfile which is not considered directly part of the application and 
is perhaps chosen by the user - or indirectly by the user - then it is 
impossible to check before you try and load the stackfile that the 
operation will succeed. Certainly you can check that the stackfile 
exists before you try to load it using 'there is a file', but since OSes 
are pre-emptive, in between doing that check and trying to load it, 
another process could have done something to invalidate the check.

Of course, in the above the assumption we are making is that the 
'stackfiles which are part of the application' are not amenable to being 
fettled with by other processes - in the sandboxed model (such as you 
get on iOS and Android) this is enforced, in unsandboxed worlds you have 
to squint a bit to convince yourself that this is actually a reasonable 
thing to assume. (After all, if you go into an installed applications 
folder on any platform and start deleting arbitrary files from them, you 
can't really expect them to function at all!).

So, anyway, my question has been answered :)

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps