Re: Does anyone have "assert" blindness ?

[<jgiors@...>]

> -------- Original Message --------
> Date: Wed, 09 Mar 2011 18:44:14 +0100
> From: Peter Odding <peter@peterodding.com>
> Subject: Re: Does anyone have "assert" blindness ?
> To: Lua mailing list <lua-l@lists.lua.org>
> Message-ID: <4D77BC6E.1080400@peterodding.com>
> Content-Type: text/plain; charset=UTF-8
> 
> 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

I don't know if this is the kind of thing that might help, but if you
really want to check the return values every time, you can wrap the
functions:

--[] WARNING! THIS IS UNTESTED SAMPLE CODE! [1]
--[] 
--[] local function wrap(f)
--[]   return function(...) return assert(f(...)) end
--[] end
--[]
--[] function someFunc(arg)  --this represents a lib func
--[]   if arg then print("All good!")
--[]   else return nil, "Oh oh!"
--[]   end
--[] end
--[] 
--[] someFunc = wrap(someFunc)

Hopefully that gives you an idea, or something similar might be useful.
Of course, it means you won't get nice assert messages tailored to each
point of use, and it adds an extra function call.

John Giors
http://ThreeEyesSoftware.com
jgiors@ThreeEyesSoftware.com

[1] Sorry, I would have tested the code, but my computer bricked and my
new system isn't completely set up.