Re: Error handling (was Re: "nan" v. try-catch for arithmetic)

[Paul Dupuis]

On 6/26/2014 12:23 PM, Peter Haworth wrote:
> On Thu, Jun 26, 2014 at 8:22 AM, Richard Gaskin 
> wrote:
>
>> Is there a simple rule that would allow scripters to understand when
>> try-catch is necessary and when the result should be checked instead?
>>
>> If not, should there be?
>>
>> Or perhaps better yet, could error handling be made uniform, maybe as part
>> of the Open Language initiative?  If so, what would it look like?
>>
> Personally, I think error handling should be made uniform.  As you say,
> sometimes try/catch is required, other times the result must be checked and
> sometimes "it" must be checked.  Then there's the different ways errors are
> reported by the database library commands.
>

Try - Catch functionally is present many programming languages for a
very different purpose than general error reporting.

Language commands and functions that can detect, trap, and report an
error, should return appropriate error information that the programmer
can check for. LC generally does this via "the result", the returned
value of a function itself (an empty return value from some functions
can equal an error condition, or a function may return an error
message), or "it" - and among these, improved consistency would be a
nice improvement.

However, no language can really prevent programming error or error based
on unexpected inputs - i.e. add "fred" to tVar - that results in an
execution error.

Try/Catch serves as a tool in modern programming languages to allow a
programmer to catch any UNEXPECTED execution error and handle it in some
controlled way.

Both mechanism can be used together. In the example below, if tInput
contained text ("fred") rather than a number or if either "someFunction"
or "someCommand return errors, the entire block of code has a graceful exit.

try
 add tInput  to tVar
 put someFuntion(tVar) into tVar2
 if tVar2 is empty throw error
 someCommand tVar2
 if the result begins with "error" then throw error
catch tError
 -- controlled exit here
end try

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Error handling (was Re: "nan" v. try-catch for arithmetic)

[Peter Haworth]

On Thu, Jun 26, 2014 at 8:22 AM, Richard Gaskin 
wrote:

> Is there a simple rule that would allow scripters to understand when
> try-catch is necessary and when the result should be checked instead?
>
> If not, should there be?
>
> Or perhaps better yet, could error handling be made uniform, maybe as part
> of the Open Language initiative?  If so, what would it look like?
>

Personally, I think error handling should be made uniform.  As you say,
sometimes try/catch is required, other times the result must be checked and
sometimes "it" must be checked.  Then there's the different ways errors are
reported by the database library commands.

Maybe there should a new variable - the error for example - which can be
used to report all error conditions.  Another approach might be the ability
to specify a error callback handler similar to the libURL commands.

Pete
lcSQL Software 
Home of lcStackBrowser  and
SQLiteAdmin 
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Error handling (was Re: "nan" v. try-catch for arithmetic)

[Richard Gaskin]

J. Landman Gay wrote:
> On 6/24/2014, 1:02 PM, Graham Samuel wrote:
>> I get a result, "nan", and the catch doesn't fire. Why not? Maybe
>> someone can explain what the engine is doing here - or is it just an
>> obscure bug?
>
> A "catch" only triggers when there is a script error. In this case
> there is no error, "nan" is a legitimate value for a calculation
> that can't be computed.

This conversation raises a broader issue that's concerned me for some 
time, and I'm hoping I've just overlooked some rule at play that would 
make things more readily understandable:


How can a scripter know in advance which commands require try-catch to 
handle errors and which require checking the result?


For example:

decompress and arrayDecode require try-catch, throwing an execution 
error if the data passed to them is not in the expected format.


But decrypt throws no execution error at all when unencrypted data is 
passed, instead describing that there is a problem in the result.



Is there a simple rule that would allow scripters to understand when 
try-catch is necessary and when the result should be checked instead?


If not, should there be?

Or perhaps better yet, could error handling be made uniform, maybe as 
part of the Open Language initiative?  If so, what would it look like?


--
 Richard Gaskin
 Fourth World
 LiveCode training and consulting: http://www.fourthworld.com
 Webzine for LiveCode developers: http://www.LiveCodeJournal.com
 Follow me on Twitter:  http://twitter.com/FourthWorldSys



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode