[Chicken-users] Handling Errors

2014-12-14 Thread Bahman Movaqar
Consider the following simple function:

  (define (foo lis) (cdr lis))

Obviously LIS should neither be an empty list nor a list with only one
element.
What is the recommended way to deal with such constraints? Should I
enforce them by writing conditionals at the beginning of the
function[1]? Or is it conventional to just let the function fail and
catch the error somewhere else (probably in a top-level function)?

[1] This quickly leads to dirty and not-easy-to-read code.

What say you seasoned schemers on this?

-- 
Bahman Movaqar

http://BahmanM.com - https://twitter.com/bahman__m
https://github.com/bahmanm - https://gist.github.com/bahmanm
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)




signature.asc
Description: OpenPGP digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Handling Errors

2014-12-14 Thread Andy Bennett


Hi,

   (define (foo lis) (cdr lis))

 Obviously LIS should neither be an empty list nor a list with only one
 element.
 What is the recommended way to deal with such constraints? Should I
 enforce them by writing conditionals at the beginning of the
 function[1]? Or is it conventional to just let the function fail and
 catch the error somewhere else (probably in a top-level function)?

 [1] This quickly leads to dirty and not-easy-to-read code.

 What say you seasoned schemers on this?

That depends on the scope of the accessor. I often use these kinds of
things for quick and dirty data structures for passing seeds for fold
around. In that case I use the even more concise '(define foo cdr)'.

In the case where other modules are using the API then I might go to
more trouble but then you have to think about whether, in the error cases:

 + To return successfully with a sentinel value.
   This is valid in some cases, depending on the data semantics. It can
   be implemented using the conditionals that you mention.

 + To use assert at the head of the procedure to validate the data
   structure. This doesn't stop the error but it gives a more debuggable
   message.

 + To catch and re-throw the exception.
   This is fraught with anti-patterns, is a lot of work and you have to
   do it really carefully. I hardly ever do this.




Regards,
@ndy

-- 
andy...@ashurst.eu.org
http://www.ashurst.eu.org/
0x7EBA75FF




signature.asc
Description: OpenPGP digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users


Re: [Chicken-users] Handling Errors

2014-12-14 Thread Bahman Movaqar
On 12/14/2014 05:13 PM, Andy Bennett wrote:
 Hi,

   (define (foo lis) (cdr lis))

 Obviously LIS should neither be an empty list nor a list with only one
 element.
 What is the recommended way to deal with such constraints? Should I
 enforce them by writing conditionals at the beginning of the
 function[1]? Or is it conventional to just let the function fail and
 catch the error somewhere else (probably in a top-level function)?

 [1] This quickly leads to dirty and not-easy-to-read code.

 What say you seasoned schemers on this?
 That depends on the scope of the accessor. I often use these kinds of
 things for quick and dirty data structures for passing seeds for fold
 around. In that case I use the even more concise '(define foo cdr)'.

 In the case where other modules are using the API then I might go to
 more trouble but then you have to think about whether, in the error cases:

  + To return successfully with a sentinel value.
This is valid in some cases, depending on the data semantics. It can
be implemented using the conditionals that you mention.

This one is really tricky. Not only pollutes the API code but also it
also imposes some untidiness on the client side too which has to check
if a sentinel value has been returned or not.


  + To use assert at the head of the procedure to validate the data
structure. This doesn't stop the error but it gives a more debuggable
message.

By the gods! Why did I think that asserts only belong to modern'ish
languages? :-)
Assuming you're talking about this
(http://api.call-cc.org/doc/chicken/special-forms/assert), I believe
this is the best option. Keeps the code as clean as possible while
ensuring operational soundness.



  + To catch and re-throw the exception.
This is fraught with anti-patterns, is a lot of work and you have to
do it really carefully. I hardly ever do this.

Never! :-)

Thanks for the detailed answer. Much appreciated.

-- 
Bahman Movaqar

http://BahmanM.com - https://twitter.com/bahman__m
https://github.com/bahmanm - https://gist.github.com/bahmanm
PGP Key ID: 0x6AB5BD68 (keyserver2.pgp.com)




signature.asc
Description: OpenPGP digital signature
___
Chicken-users mailing list
Chicken-users@nongnu.org
https://lists.nongnu.org/mailman/listinfo/chicken-users