Open Gerold103 opened 3 years ago
@Mons shares this responsibility with developers. I don't think that decisions could be made in such a way: without any good shaped discussion.
Heavily support this decision. If only my voice matters :)
I don't know motivation behind this though.
I guess I can share some thoughts, but it definitely better to ask @Mons himself (consider the include below).
#include <disclaimer.h>
These are Lua world functions, so it's preferably to implement Lua-way error handling. Unfortunately there are functions in the platform implementing Go-like error handling. Strictly saying they are not, since the error handling and unwinding in Go and Lua differs. IIRC, Go obligies user to explicitly assign the second return value (i.e. the returned error) to the variable, even to omit it (just load it to _
). It doesn't work this way in Lua and the error is simply lost if user forgets to handle it. As a result, user has no idea something went wrong.
Lua implements another machinery to raise and catch errors, that is quite similar to C++ one (at least the unwinder in Tarantool build uses the same interfaces). User has to explicitly "catch" the raised error via pcall, otherwise it is propagated further. Ergo, user definitely knows what and where went wrong using the native Lua error machinery.
Audience/target: Tarantool developers Root document: https://www.tarantool.io/en/doc/latest/dev_guide/lua_style_guide/
@Mons has decided, that all Lua functions should now throw errors instead of returning them as
nil, err
like before. On the other hand, he says this is only for Tarantool functions. Not for module functions.That does not affect any of the existing functions, and is only a rule for the new ones. Must be added to Lua style guide.
I don't know motivation behind this though. Suggest to ask @Mons.