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

[Konstantin Osipov <kostja@...>]

* Tom N Harris <whoopdedo@whoopdedo.org> [15/04/28 20:28]:

> 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. 

The most common case is when you don't want to check for errors,
since all you care is that the transaction is aborted on error. 

If we had a non-throwing insert(), we'd end up with 2 versions of
the API. What we could do, of course, is to have a function, which 
could be redefined, which is responsible for raising the
exception. But that's another way of tweaking pcall()/xpcall(). 

> 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?

It's, generally, a cathedral vs. bazaar question. I have seen 
on this list that pcall() is wrapped to achieve a specific exception
handling semantics. But I haven't seen any tweak that would stand
out as a novel and interesting way to deal with errors. Mostly
everyone is wrapping it to their taste and to achieve a subset of
what you can get out of the box in most modern languages.

In any case, an easy to use syntax doesn't by itself preclude
customization.

> And global variables makes my skin crawl. What's the value of lasterror after 
> a successful call?

It's not really global, the same way as errno in C isn't. The semantics
is pretty much the same.

> What if you have to call another function before handling 
> the error?

You're suggesting perhaps that chained exceptions and push/pop of
the diagnostics area are good features. Quite likely we'll add
them in the future.
These are properties of your runtime & programming style, having
them out of the box in the language is not obviously a win.

Please don't get me wrong, I'm not suggesting that something like
lasterror makes it into Lua language. It's ugly. But one of the
reasons we had to invent lasterror was to separate more clearly
concerns of try, catch, and finally.
If you asked me about the specific syntax suggestion for Lua, I
would not know.

> 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?

We actually throw C++ objects most of the time. We also made a
binding for our own raise(), which creates a C++ object under
the hood. 

Perhaps it will become more clear after reading:

http://tarantool.org/doc/book/box/box_error.html
https://github.com/tarantool/tarantool/issues/314

-- 
http://tarantool.org - a NoSQL database in a Lua script