Error handling
Posted: Thu Feb 12, 2015 11:18 pm
In LiveCode we have two very different ways of discovering when our code doesn't work:
1. Sometimes we have to check "the result"
2. Sometimes an execution error is thrown
2a. Sometimes an execution error is reported with a scriptError message (desktop, mobile)
2b. Sometimes an execution error is reported with scriptExecutionError (Server)
Why is it that attempting to convert a date requires checking the result, while attempt to decode an array throws an execution error? And why are there two different messages for execution errors depending on which engine our script happens to be running under at the time?
Could v8 be an opportunity to consider having just one way to handle errors?
A while back I submitted a request for one possible way to do this, with a function called scriptError:
http://quality.runrev.com/show_bug.cgi?id=13573
I'm not necessarily married to that, and maybe there are better options we could consider.
Let's brainstorm some ideas.
It may turn out that the best possible solution is to continue teaching newcomers a variety of "sometimes" rules and hope they remember them all.
And maybe they're not "sometimes" rules at all, but governed by some overarching principle currently unknown to me and most of my peers which if explained might allow us to predict how we need to handle errors for any command without having to look it up in the Dictionary.
But maybe there's a simpler, more unified way to handle errors.
What would you like to see for error handling?
1. Sometimes we have to check "the result"
2. Sometimes an execution error is thrown
2a. Sometimes an execution error is reported with a scriptError message (desktop, mobile)
2b. Sometimes an execution error is reported with scriptExecutionError (Server)
Why is it that attempting to convert a date requires checking the result, while attempt to decode an array throws an execution error? And why are there two different messages for execution errors depending on which engine our script happens to be running under at the time?
Could v8 be an opportunity to consider having just one way to handle errors?
A while back I submitted a request for one possible way to do this, with a function called scriptError:
http://quality.runrev.com/show_bug.cgi?id=13573
I'm not necessarily married to that, and maybe there are better options we could consider.
Let's brainstorm some ideas.
It may turn out that the best possible solution is to continue teaching newcomers a variety of "sometimes" rules and hope they remember them all.
And maybe they're not "sometimes" rules at all, but governed by some overarching principle currently unknown to me and most of my peers which if explained might allow us to predict how we need to handle errors for any command without having to look it up in the Dictionary.
But maybe there's a simpler, more unified way to handle errors.
What would you like to see for error handling?