Skip to content

Commit 1ee65e9

Browse files
committed
Add error handling section to lua style guide
1 parent 65d2263 commit 1ee65e9

File tree

1 file changed

+38
-0
lines changed

1 file changed

+38
-0
lines changed

doc/1.7/dev_guide/lua_style_guide.rst

Lines changed: 38 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -484,4 +484,42 @@ When you'll test your code output will be something like this:
484484
ok - checking, that tables are different
485485
...
486486
487+
===========================================================
488+
Error Handling
489+
===========================================================
490+
491+
Be generous in what you accept and strict in what you return.
492+
493+
With error handling this means that you must provide an error object as second
494+
multi-return value in case of error. The error object can be a string, a Lua
495+
table or cdata, in the latter cases it must have ``__tostring`` metamethod
496+
defined.
497+
498+
In case of error, use ``nil`` for the first return value. This makes the error
499+
hard to ignore.
500+
501+
When checking function return values, check the first argument first. If it's
502+
``nil``, look for error in the second argument:
503+
504+
.. code-block:: lua
505+
506+
local data, err = foo()
507+
if not data
508+
return nil, err
509+
end
510+
return bar(data)
511+
512+
Unless performance of your code is paramount, try to avoid using more than two
513+
return values.
514+
515+
In rare cases you may want to return ``nil`` as a legal return value. In this
516+
case it's OK to check for error first, and return second:
517+
518+
.. code-block:: lua
519+
520+
local data, err = foo()
521+
if not err
522+
return data
523+
end
524+
return nil, err
487525

0 commit comments

Comments
 (0)