Скрипт на луа ошибки

(This was originally meant as a reply to the first comment to Krtek’s question, but I ran out of space there and to be honest it works as an answer just fine.)

Functions are essentially values, and thus a named function is actually a variable of that name. Variables, by their very definition, can change as a script is executed. Hell, someone might accidentally redefine one of those functions. Is that bad? To sum my thoughts up: depending on the script, parameters passed and/or actual implementations of those pre-defined functions you speak of (one might unset itself or others, for example), it is not possible to guarantee things work unless you are willing to narrow down some of your demands. Lua is too dynamic for what you are looking for.

If you want a flawless test: create a dummy environment with all bells and whistles in place, and see if it crashes anywhere along the way (loading, executing, etc). This is basically a sort of unit test, and as such would be pretty heavy.

If you want a basic check to see if a script has a valid syntax: Krtek gave an answer for that already. I am quite sure (but not 100%) that the lua equivalent is to loadfile or loadstring, and the respective C equivalent is to try and lua_load() the code, each of which convert readable script to bytecode which you would already need to do before you could actually execute the code in your normal all-is-well usecase. (And if that contained function definitions, those would need to be executed later on for the code inside those to execute.)

However, these are the extent of your options with regards to pre-empting errors before they actually happen. Lua is a very dynamic language, and what is a great strength also makes for a weakness when you want to prove correctness. There are simply too many variables involved for a perfect solution.

Всем привет, с каждым днем на форуме появляется все больше тем, связанных с неработоспособностью некоторых скриптов. В этой мини-статье я постараюсь показать Вам как можно самому решить некоторые проблемы и не засорять форум.

Поиск ошибки
Для поиска проблем нам необходимо открыть moonloader.log ("папка с игрой"moonloadermoonloader.log). Мунлог хранит в себе информацию о работе всех .lua/.luac скриптов. Открыть мунлог можно используя любой текстовый редактор.
После открытия мунлога Вам необходимо найти строку, которая содержит название скрипта и слово «error», сделать это можно даже используя функцию поиска по текстовому документу (CTRL + F).

Нет файла moonloader.log?
Файл moonloader.log должен появится в любом случае (даже если игра крашится). Если же у вас его нет, то это значит что не работает сам moonloader. Убедитесь что у вас установлен ASI Loader и есть файл moonloader.asi в папке с игрой.

Примеры ошибок​

Пример №1. Отсутствие библиотеки

[00:14:16.642461] (error)   helper lovli privat: D:GTA 130K BY DAPO SHOWmoonloaderHelpLovlZin.lua:5: module 'imgui' not found:

В данной строке мы видим название скрипта (это может быть или название файла или текст указанный автором скрипта через script_name), путь к файлу скрипта, строку на которой произошла ошибка и текст самой ошибки.

В этом случае:

• название — «helper lovli privat«
• файл — «D:GTA 130K BY DAPO SHOWmoonloaderHelpLovlZin.lua«
• строка — «5«
• ошибка — «module 'imgui' not found«

Для решения данной проблемы нам необходимо знать английский на «базовом» уровне, ну или научится использовать переводчик. После перевода ошибки на русский мы понимаем что скрипт не может найти модуль «imgui» (в данном случае модуль = библиотека). Что бы решить эту ошибку нам надо просто установить imgui. Если ошибка связана с отсутствием модулей sampfuncs.lua, moonloader.lua, vector3d.lua, bitex.lua или matrix3x3.lua, то Вам необходимо переустановить moonloader: https://www.blast.hk/threads/13305/.

Пример №2. cannot load incompatible bytecode

[21:22:16.064337] (error)    MHManager.luac: C:GamesARIZONA GAMESbinArizonamoonloaderMHManager.luac: cannot load incompatible bytecode

Данная ошибка связана с «несовместимостью» скрипта с вашей версией moonloader. Для начала стоит узнать вашу версию moonloader. Что бы это сделать смотрим на 4 строку в moonloader.log. В нашем случае версия мунлоадера «v.026.5-beta loaded.«, это значит что «вылетевший» скрипт скомпилирован для версии мунлоадера 0.25. Для исправления ошибки можете установить этот скрипт: https://www.blast.hk/threads/35380/.

Пример №3. Неверное написание кода
Небольшое дополнение первого примера: в некоторых случаях вместо пути к файлу самого скрипта может быть путь к файлу библиотеки, например:

Для «уточнения» причины стоит ввести текст в переводчик. В данном случае ошибка произошла в файле moonloaderlibrequests.lua. Вероятнее всего ошибка была вызвана неправильным использованием функции библиотеки в самом скрипте.

[21:05:59.066798] (error)    weaptag.lua: opcode '0B2B' call caused an unhandled exception
[21:05:53.400168] (error)    mimgui_shadow.lua: X:SAMP Medium PC by chapomoonloadermimgui_shadow.lua:77: attempt to call global 'doesFileExists' (a nil value)
[21:19:56.473206] (error)    skinbreaker.lua: X:SAMP Medium PC by chapomoonloaderskinbreaker.lua:26: unexpected symbol near '<eof>'
[21:20:21.228567] (error)    skinbreaker.lua: X:SAMP Medium PC by chapomoonloaderskinbreaker.lua:25: 'end' expected (to close 'function' at line 19) near '<eof>'
и т.д

Такие сообщения связаны с неверным написанием кода, Вам следует написать автору скрипта.

Пример №4. Microsoft Visual C++ Runtime Libruary (imgui_draw.cpp Line: 1314)

Ошибка связана с отсутствием шрифта, необходимого для работы скрипта. Чаще всего с такой ошибкой сталкиваются из-за отсутствия шрифта Font Awesome. Установить файлы FontAwesome можно тут: https://www.blast.hk/threads/111224/.

Пример №5. Ошибки с GET request

[20:12:23.455320] (error)    Rvanka-taker.luac: C:GamesGTA 140K BY DAPO SHOWmoonloaderlibrequests.lua:106: error in GET request: timeout

В этом случае нам нужно сделать то же самое что и в первом примере (перевести и загуглить).

Примеры (причины и решения) ошибок будут пополнятся.​

*moonloader.log — это текстовый файл, находящийся по пути папка с игройmoonloadermoonloader.log, он хранит в себе информацию о работе всех .lua/.luac скриптов.

Во время скриптинга вы часто будете встречать проблемы, незаметные с первого взгляда. Эта страница покажет вам некоторые базовые стратегии локализирования ошибок.

Консоль отладки

MTA предоставляет встроенную консоль отладки, которая показывает отладочные сообщения от функций и скриптов MTA. Ее можно открыть, введя в консоли debugscript x, где x — уровень отладки:

• 1: только ошибки
• 2: ошибки и предупреждения
• 3: ошибки, предупреждения и информационные сообщения

Таким образом, при вводе debugscript 3 видны все сообщения, так что либо этот, либо уровень 2 рекомендованы в большинстве случаев. debugscript следует иметь включенным на протяжении практически всего времени, когда тестируете свои скрипты, это поможет в обнаружении опечаток и других мелких ошибок, позволяя с легкостью их поправить.

Пример

В этом отрывке две ошибки:

if (getPlayerName(player) == "Fedor")
    outputChatbox("Hello Fedor")
end

Когда скрипт, в котором присутствует данный отрывок кода попробует загрузиться, debugscript выведет что-то типа этого:

INFO: Loading script failed: C:<server path>modsdeathmatchresourcesmyResourcescript.lua:15: ‘then’ expected near ´outputChatbox’

Это значит, что скрипт не может быть обработан в силу синтаксической ошибки. Показывается путь ко скрипту, чтобы можно было также увидеть, частью какого ресурса он является (‘myResource’ в данном случае), и, конечно, имя самого скрипта. После имени файла показан номер строки и что в ней, собственно, не так. Теперь все с легкостью можно исправить, мы просто забыли оператор ‘then’:

if (getPlayerName(player) == "Fedor") then
    outputChatbox("Hello Fedor")
end

Сейчас скрипт нормально загрузится и не выведет никаких ошибок, но только пока не выполнится для игрока с ником ‘Fedor’. В этом случае, debugscript выведет:

ERROR: C:<server path>modsdeathmatchresourcesdscript.lua:15: attempt to call global ‘outputChatbox’ (a nil value)

То есть, что вызванной функции не существует, что и не удивительно, так как ее правильное название — outputChatBox (с заглавной B):

if (getPlayerName(player) == "Fedor") then
    outputChatBox("Hello Fedor")
end

Это, конечно, лишь пример, есть еще море других сообщений и сценариев, но вам теперь должна быть понятна сама суть.

Ведение отладочного лога на сервере и клиенте

Сервер

Перейдите в: (корневая папка MTA)>server>mods>deathmatch
Там есть два практически одинаковых файла:

• local.conf — содержит настройки сервера, доступного по нажатию на пункт «host game» главного меню MTA. Это быстрый и простой путь ненадолго запустить сервер извнутри клиента. При выключении клиента выключится и сервер.
• mtaserver.conf — используется при выполнении запуска «MTA Server.exe» из (корневая папка MTA)>server. Это способ запустить сервер независимо от клиента на продолжительное время.

В зависимости от выбранного вами способа, вам захочется отредактировать один из этих файлов. Настройки, интересные нам:

<!-- Задает имя и путь лог-файла debugscript. Если оставить пустым, такой файл создан не будет. -->
    <scriptdebuglogfile>logs/scripts.log</scriptdebuglogfile> 
    
    <!-- Задает уровень лог-файла debugscript. Допустимые значения: 0, 1, 2, 3. Если не установить, по умолчанию будет 0. -->
    <scriptdebugloglevel>0</scriptdebugloglevel>

Убедитесь, что указали имя лога. Также укажите уровень ошибок, которые будут записываться. При указании 0 ничего не будет записываться. Другие уровни были объяснены в начале данной статьи. При смене уровня записи на 3, все ошибки серверных скриптов будут записаны в (корневая папка MTA)>server>mods>deathmatch>logs>scripts.log

Клиент

Перейдите в: (корневая папка MTA)>server>clientscript.log
В этот файл ведется запись ошибок всех клиентских скриптов. Запись включена по умолчанию, вмешательств не требуется.

Стратегии отладки

Есть несколько стратегий, помогающих в поиске ошибок, мы говорим об отличных от непосредственного просмотра кода, конечно же. Большинство из них включает в себя вывод отладочных сообщений с варьирующейся от ситуации к ситуации информацией.

Полезные функции

Для начала, некоторые функции, которые могут оказаться удобными при отладке.

• outputDebugString или outputChatBox для вывода информации любого вида
• tostring() обращает переменную в строковую, например, когда она является бинарной (двоичной)
• getElementType для выполнения проверки элемента MTA на получение его типа

Добавляйте отладочные сообщения, чтобы проверять когда, как часто и вообще, выполняется ли участок кода

Типичный пример проверки на выполнение участка с if. Чтобы его сделать, просто добавьте любое сообщение, которое вы потом будете в состоянии понять, внутрь участка с if.

if (variable1 == variable2) then
    outputDebugString("вошел в if")
    -- что-нибудь делаем
end

Другое применение — проверка переменной на предмет ее изменения. Для начала найдите все случаи, где переменная редактируется, и добавьте сообщения прямо рядом с ней.

Добавляйте отладочные сообщения для проверки значения переменной

Скажем, вы создали маркер, но он не появляется на той позиции, на которой вы этого хотели бы. Первое, что вы захотите сделать — проверить, была ли выполнена функция createMarker. Но одновременно с этим вы также можете проверить и значения, используемые при выполнении функции createMarker, всего за один запуск.

outputChatBox("posX - "..x.." posY - "..y.." posZ - "..z)
createMarker(x,y,z)

Это выведет в консоль отладки все три переменные, используемые в качестве коодинат для маркера. Подразумевая, что у вас они считываются из map-файла, теперь вы сможете сравнить выведенное в консоль с желаемыми значениями. tostring() гарантирует, что значения переменных смогут быть выведены вместе строкой, даже если они, например, двоичные.

Пример

Представьте, что где-то вы создали колшейп (collision shape) и хотите производить какое-либо действие над игроком, простоявшим в нем 10 секунд.

function colShapeHit(player)
    -- устанавливаем таймер на вывод сообщения (можно также вызвать другую функцию)
    -- сохраняем id таймера в таблице, используя игрока как индекс
    colshapeTimer[player] = setTimer(outputChatBox,10000,1,"Игрок задержался в колшейпе на 10 секунд!")
end
addEventHandler("onColShapeHit",getRootElement(),colShapeHit)

function colShapeLeave(player)
    -- убираем таймер при покидании игроком колшейпа
    killTimer(colshapeTimer[player])
end
addEventHandler("onColShapeLeave",getRootElement(),colShapeLeave)

При попадании игрока в колшейп, в консоль отладки выводится следующее сообщение:

ERROR: ..[path]: attempt to index global ‘colshapeTimer’ (a nil value)

Что значит, что вы пытались проиндексировать несуществующую таблицу. В образце выше это сделано, так как id таймера сохраняется в таблице. Нам нужно добавить проверку на то, существует ли таблица, а если нет — создать ее.

function colShapeHit(player)
    if (colshapeTimer == nil) then
        colshapeTimer = {}
    end
    -- устанавливаем таймер на вывод сообщения (можно также вызвать другую функцию)
    -- сохраняем id таймера в таблице, используя игрока как индекс
    colshapeTimer[player] = setTimer(outputChatBox,10000,1,"Игрок задержался в колшейпе на 10 секунд!")
end
addEventHandler("onColShapeHit",getRootElement(),colShapeHit)

function colShapeLeave(player)
    -- убираем таймер при покидании игроком колшейпа
    killTimer(colshapeTimer[player])
end
addEventHandler("onColShapeLeave",getRootElement(),colShapeLeave)

Но мы все же получаем предупреждение, когда игрок попадает в колшейп, ждет сообщения и снова его покидает:

WARNING: [..]: Bad argument @ ‘killTimer’ Line: ..

За исключением этого сообщения (о нем поговорим позже) все, похоже, работает правильно. Игрок попадает в колшейп, таймер стартует, если он остается, появляется сообщение, если он уходит, таймер убирается.

Более незаметная ошибка

Но, в силу некоторых обстоятельств, сообщение выводится дважды, если вы остаетесь в колшейпе на транспортном средстве. Если так получается, значит какой-то код выполняется дважды, мы добавим отладочные сообщения для проверки.

function colShapeHit(player)
    if (colshapeTimer == nil) then
        colshapeTimer = {}
    end
    -- добавляем отладочное сообщение
    outputDebugString("colShapeHit")
    -- устанавливаем таймер на вывод сообщения (можно также вызвать другую функцию)
    -- сохраняем id таймера в таблице, используя игрока как индекс
    colshapeTimer[player] = setTimer(outputChatBox,10000,1,"Игрок задержался в колшейпе на 10 секунд!")
end
addEventHandler("onColShapeHit",getRootElement(),colShapeHit)

function colShapeLeave(player)
    -- добавляем отладочное сообщение
    outputDebugString("colShapeLeave")
    -- убираем таймер при покидании игроком колшейпа
    killTimer(colshapeTimer[player])
end
addEventHandler("onColShapeLeave",getRootElement(),colShapeLeave)

Теперь мы точно видим, что обе функции, прикрепленные к обработчикам, выполняются дважды, если мы в ТС, или один раз, если мы вне ТС. Такое может получаться, если транспортное средство тоже вызывает срабатывание колшейпа. Чтобы подтвердить или опровергнуть эту теорию, проверим переменную player, которая должна содержать элемент типа player.

function colShapeHit(player)
    if (colshapeTimer == nil) then
        colshapeTimer = {}
    end
    -- добавляем отладочное сообщение, с типом элемента
    outputDebugString("colShapeHit "..getElementType(player))
    -- устанавливаем таймер на вывод сообщения (можно также вызвать другую функцию)
    -- сохраняем id таймера в таблице, используя игрока как индекс
    colshapeTimer[player] = setTimer(outputChatBox,10000,1,"Игрок задержался в колшейпе на 10 секунд!")
end
addEventHandler("onColShapeHit",getRootElement(),colShapeHit)

function colShapeLeave(player)
    -- добавляем отладочное сообщение, с типом элемента
    outputDebugString("colShapeLeave "..getElementType(player))
    -- убираем таймер при покидании игроком колшейпа
    killTimer(colshapeTimer[player])
end
addEventHandler("onColShapeLeave",getRootElement(),colShapeLeave)

Отладочные сообщения говорят, что одна из переменных player — действительно игрок, а другая — элемент типа vehicle, т.е. ТС. Так как мы хотим, чтобы срабатывание происходило при попадании в колшейп именно игрока, добавляем if, который предотвратит выполнение функции, если в него попал не игрок (не элемент типа player).

function colShapeHit(player)
    if (colshapeTimer == nil) then
        colshapeTimer = {}
    end
    -- добавляем проверку на тип элемента
    if (getElementType(player) ~= "player") then return end
    -- добавляем отладочное сообщение, с типом элемента
    outputDebugString("colShapeHit "..getElementType(player))
    -- устанавливаем таймер на вывод сообщения (можно также вызвать другую функцию)
    -- сохраняем id таймера в таблице, используя игрока как индекс
    colshapeTimer[player] = setTimer(outputChatBox,10000,1,"Игрок задержался в колшейпе на 10 секунд!")
end
addEventHandler("onColShapeHit",getRootElement(),colShapeHit)

function colShapeLeave(player)
    -- добавляем проверку на тип элемента
    if (getElementType(player) ~= "player") then return end
    -- добавляем отладочное сообщение, с типом элемента
    outputDebugString("colShapeLeave "..getElementType(player))
    -- убираем таймер при покидании игроком колшейпа
    killTimer(colshapeTimer[player])
end
addEventHandler("onColShapeLeave",getRootElement(),colShapeLeave)

Теперь скрипт должен работать как задумано, но все еще будет выводить предупреждение, о котором было сказано ранее. Это происходит, так как таймер, который мы пытаемся убрать при покидании игроком колшейпа, не будет более существовать по прошествии 10 секунд (уже истек). Есть множество способов избавиться от этого предупреждения (вы же знаете, что таймер может более не существовать, и вы хотите его убрать, только если он еще существует). Одним из способов является проверка на то, существует ли упоминаемый в таблице таймер на самом деле. Чтобы ее сделать, нам понадобится isTimer, которой мы и воспользуемся при убирании таймера:

if (isTimer(colshapeTimer[player])) then
    killTimer(colshapeTimer[player])
end

Итак, полностью рабочий код таков:

function colShapeHit(player)
    if (colshapeTimer == nil) then
        colshapeTimer = {}
    end
    -- добавляем проверку на тип элемента
    if (getElementType(player) ~= "player") then return end
    -- добавляем отладочное сообщение, с типом элемента
    outputDebugString("colShapeHit "..getElementType(player))
    -- устанавливаем таймер на вывод сообщения (можно также вызвать другую функцию)
    -- сохраняем id таймера в таблице, используя игрока как индекс
    colshapeTimer[player] = setTimer(outputChatBox,10000,1,"Игрок задержался в колшейпе на 10 секунд!")
end
addEventHandler("onColShapeHit",getRootElement(),colShapeHit)

function colShapeLeave(player)
    -- добавляем проверку на тип элемента
    if (getElementType(player) ~= "player") then return end
    -- добавляем отладочное сообщение, с типом элемента
    outputDebugString("colShapeLeave "..getElementType(player))
    -- убираем таймер при покидании игроком колшейпа
    if (isTimer(colshapeTimer[player])) then
        killTimer(colshapeTimer[player])
    end
end
addEventHandler("onColShapeLeave",getRootElement(),colShapeLeave)

Отладка проблем с производительностью

Если ваш сервер использует намного больше ресурсов, чем ему следовало бы, или вы просто хотите убедиться, что ваши скрипты эффективны, вы можете узнать правду, воспользовавшись отличным инструментом, который поставляется вместе с сервером MTA SA — performancebrowser. Удостоверьтесь, что он запущен, введя «start performancebrowser», а если у вас его нет, возьмите из комплекта стандартных ресурсов, поставляемых с сервером. Данный инструмент предоставляет потрясающее количество информации, полезной для отладки проблем с производительностью. Утечки памяти, утечки элементов и интенсивно использующие процессор скрипты легко найти через performancebrowser. Например, при использовании опции -d в Lua timing, вы можете увидеть, какие функции сильно загружают процессор.
Для доступа к performancebrowser вам понадобится перейти по адресу: http://здесьIPсервера:здесьHTTPпортсервера/performancebrowser/ в своем интернет-браузере. Заметьте, что в конце требуется символ / (слэш). То есть, например: http://127.0.0.1:22005/performancebrowser/ Затем вам понадобится войти со внутриигрового администраторского аккаунта или любого другого аккаунта, имеющего доступ к «general.HTTP». Большинство нужной вам информации находится в разделах Lua timing и Lua memory, там смотрите на те показатели, которые значительно превышают другие.

Примеры скриптов, которые могут вызывать провалы производительности

Добавление данных в таблицу без последующего удаления. Хотя пройдут месяцы/годы, пока это реально вызовет какие-либо проблемы.

local someData = {}

function storeData()
    someData[source] = true
    -- Здесь не учитывается выход игрока, что вызовет утечку памяти
    -- Используя вкладку Lua timing, вы можете обнаружить использование RAM каждым из ресурсов.
end
addEventHandler("onPlayerJoin", root, storeData)

Утечка элементов возможна при использовании по какой-либо причине множества временных колшейпов и последующем их неустранении. Через некоторое время это повлечет за собой проблемы с пропускной способностью, расходом процессора и памяти сервера.

function useTemporaryCol()
    local col = createColCircle(здесь какой-нибудь код)
    if (нормальные для этого условия) then
        destroyElement(col)
    end
    -- Но иногда этого не происходит, так что даже по окончании скрипта зона коллизии остается, что впоследствии
    -- может вылиться в сотни, а то и тысячи бесполезных зон коллизии. 
    -- Вкладка Lua timing позволит вам увидеть количество элементов, созданных каждым скриптом.
end

Большой расход процессора чреват тем, что выливается в просадку FPS сервера до порога, когда тот становится неиграбельным. Менее чем за 24 часа это может превратить даже самый популярный сервер в пустующий. Количество «refs» в Lua timing обнаруживает данный тип скопления, удивительно, но вкладка Lua timing в данном случае не помогла, когда Lua memory — напротив.

addEventHandler("onPlayerJoin", root, function()
    -- Код для заходов
    addEventHandler("onPlayerQuit", root, function()
        -- Код для того, когда выходят
        -- Видите проблему? Он привязан к корню (root), к которому обработчик добавляется снова, снова и снова
    end)
end)

Функция интенсивно использует процессор, потому что то, что она выполняет, занимает много времени. Это просто функция, которой для завершения требуется много времени. Без performancebrowser вы бы и не догадывались, в чем причина, но с performancebrowser вы можете увидеть, что ресурс сильно загружает процессор во вкладке Lua timing. Если вы затем введете: -d в редактируемое поле options, он даже скажет название файла и первую строку функции, которая так сильно загружает процессор.

function someDodgyCode()
    for i=1, 100000 do
        -- какой-нибудь код
    end
end

---

Need for Error Handling

Error handling is quite critical since real-world operations often require the use of complex operations, which includes file operations, database transactions and web service calls.

In any programming, there is always a requirement for error handling. Errors can be of two types which includes,

• Syntax errors
• Run time errors

Syntax Errors

Syntax errors occur due to improper use of various program components like operators and expressions. A simple example for syntax error is shown below.

a == 2

As you know, there is a difference between the use of a single «equal to» and double «equal to». Using one instead of the other can lead to an error. One «equal to» refers to assignment while a double «equal to» refers to comparison. Similarly, we have expressions and functions having their predefined ways of implementation.

Another example for syntax error is shown below −

for a= 1,10
   print(a)
end

When we run the above program, we will get the following output −

lua: test2.lua:2: 'do' expected near 'print'

Syntax errors are much easier to handle than run time errors since, the Lua interpreter locates the error more clearly than in case of runtime error. From the above error, we can know easily that adding a do statement before print statement is required as per the Lua structure.

Run Time Errors

In case of runtime errors, the program executes successfully, but it can result in runtime errors due to mistakes in input or mishandled functions. A simple example to show run time error is shown below.

function add(a,b)
   return a+b
end

add(10)

When we build the program, it will build successfully and run. Once it runs, shows a run time error.

lua: test2.lua:2: attempt to perform arithmetic on local 'b' (a nil value)
stack traceback:
	test2.lua:2: in function 'add'
	test2.lua:5: in main chunk
	[C]: ?

This is a runtime error, which had occurred due to not passing two variables. The b parameter is expected and here it is nil and produces an error.

Assert and Error Functions

In order to handle errors, we often use two functions − assert and error. A simple example is shown below.

local function add(a,b)
   assert(type(a) == "number", "a is not a number")
   assert(type(b) == "number", "b is not a number")
   return a+b
end

add(10)

When we run the above program, we will get the following error output.

lua: test2.lua:3: b is not a number
stack traceback:
	[C]: in function 'assert'
	test2.lua:3: in function 'add'
	test2.lua:6: in main chunk
	[C]: ?

The error (message [, level]) terminates the last protected function called and returns message as the error message. This function error never returns. Usually, error adds some information about the error position at the beginning of the message. The level argument specifies how to get the error position. With level 1 (the default), the error position is where the error function was called. Level 2 points the error to where the function that called error was called; and so on. Passing a level 0 avoids the addition of error position information to the message.

pcall and xpcall

In Lua programming, in order to avoid throwing these errors and handling errors, we need to use the functions pcall or xpcall.

The pcall (f, arg1, …) function calls the requested function in protected mode. If some error occurs in function f, it does not throw an error. It just returns the status of error. A simple example using pcall is shown below.

function myfunction ()
   n = n/nil
end

if pcall(myfunction) then
   print("Success")
else
	print("Failure")
end

When we run the above program, we will get the following output.

Failure

The xpcall (f, err) function calls the requested function and also sets the error handler. Any error inside f is not propagated; instead, xpcall catches the error, calls the err function with the original error object, and returns a status code.

A simple example for xpcall is shown below.

function myfunction ()
   n = n/nil
end

function myerrorhandler( err )
   print( "ERROR:", err )
end

status = xpcall( myfunction, myerrorhandler )
print( status)

When we run the above program, we will get the following output.

ERROR:	test2.lua:2: attempt to perform arithmetic on global 'n' (a nil value)
false

As a programmer, it is most important to ensure that you take care of proper error handling in the programs you write. Using error handling can ensure that unexpected conditions beyond the boundary conditions are handled without disturbing the user of the program.