Re: clumsiness of pcall() syntax and how we deal with it

[Tom N Harris <whoopdedo@...>]

On Tuesday, April 28, 2015 01:19:04 PM Konstantin Osipov wrote:
> But there are rare cases when your business logic mandates
> an action on error, and for these cases we offer people
> Lua pcall():
> 
> begin()
>     select(...)
>     status, error = pcall(insert, ...)
>     if status then
>         look at the error, take action
>     end
>     delete(...)
> commit()

If I may make an observation, why not include pcall inside the database 
functions?

    if begin() then
      select(...)
      if not insert(...) then
        -- do something else, lasterror() is valid
      end
      delete(...)
      commit()
    end

It's an ongoing conversation about when it is valid to let an error bubble up. 
One opinion is that libraries should avoid throwing errors back to the 
application. 

The problem with making your proposal a core feature is what if I want errors 
to be handled the traditional way? The current pcall can be wrapped to act in 
different ways, as you demonstrate. How much more work would it be to create a 
wrapper around your version of pcall to act like a "dumb" pcall?

And global variables makes my skin crawl. What's the value of lasterror after 
a successful call? What if you have to call another function before handling 
the error? What if a pcall throws an error that isn't a string? What if I'm 
running in a sandbox and don't have access to the top-level _ENV?

-- 
tom <telliamed@whoopdedo.org>