Re: Does anyone have "assert" blindness ?

[Peter Odding <peter@...>]

Heads up: Lots of brainstorming about the complexities of proper error
handling ahead so feel free to skip this e-mail if it doesn't interest you.

> Does anyone else have this case of acute "assert" blindness, sometimes...
> looking at some Lua code ?
> 
> Came accross some examples, where literally almost every functioncall has an
> assert(). It is somewhat painful to look thru the asserts, and actually
> figure out the logic within.
> Might like to modify SciTE syntax-highlighting config to treat assert as a
> keyword, s.t. I can atleast focus on the main logic.
> 
> Might be useful to have some syntactic sugar, like
> "require(assertion_on_everything_that_makes_sense)" s.t. at runtime
> everything is treated as if it's wrapped in an assert() !! Anyone ?

I've been bothered by the same thing for a while now and would love to
do something about it (as the author of the Lua/APR binding at least)
however I'm struggling with these two conflicting use cases:

1. (Assuming functions that return nil on error:) When you're not
expecting an error, you have to wrap every call that can fail with
assert(), but of course because you weren't expecting an error it's
likely that you'll forget the assert() and get "attempt to index a nil
value" when things eventually go wrong.

2. When you're expecting an error, checking for (nil, msg) is a lot less
complex than wrapping the function call with pcall().

For others reading along, you can see an example of what Jayanth is
talking about here:

  http://peterodding.com/code/lua/apr/docs/#example_http_client

There are 11 assertions in that one page of code. I don't think users of
the Lua/APR binding will be as disciplined about using assert() as I
have been in the example code :-(

Because of use case #2 above I think I'd rather not change the Lua/APR
binding to raise errors by default, but the flipside is that my elegant
and simple Lua code turns into error handling hell (having to check the
result of every single function call just like in good old C).

I've considered providing an apr.auto_assert() function that changes the
binding from returning (nil, msg) to raising errors, but the problem
with this is that if one call site changes this setting it will
influence all other call sites...

I'd love to hear any/everyone's thoughts about this issue: Would you
rather see a Lua module raising errors or returning (nil, msg)? Or is
there a better solution that I haven't considered?

Thanks for your time,

 - Peter Odding