Как увидеть сообщение об ошибке? Я вижу лишь «Unhandled Exception»…
Как говорится в документации, при обнаружении парсером необработанной ошибки вызывается метод @unhandled_exception[], который по умолчанию определен в конфигурационном auto.p, входящим в поставку парсера. Для того, чтобы кто ни попадя не видел текстов об ошибке, из метода @unhandled_exception[] вызывается метод @unhandled_exception_release[], который лишь сообщает, что произошла ошибка (Unhandled Exception), и для её уточнения предлагает заглянуть в parser3.log или включить debug режим, чтобы текст сообщения об ошибке выдавался на страницу. Для того, чтобы включить этот debug режим, необходимо отредактировать конфигурационный auto.p таким образом, чтобы из метода @unhandled_exception[] вызывался метод @unhandled_exception_debug[] (который как и @unhandled_exception_release[] находится в этом файле).

…parser already configured…
Такую ошибку парсер выдает когда метод @conf[] вызывается повторно.
Этот метод должен присутствовать только в конфигурационном auto.p (который находится рядом с исполняемым файлом). Необходимо проверить:
— нет ли его в других файлах
— не вызывается ли он где ручками
— не вызывается ли через use конфигурационный auto.p

…expecting 'STRING' or '$' or '^'…
Как правило это не закрытые скобки или забытый префикс в виде символа ’^’ перед спецсимволами парсера ’;’, ’^’, ’$’ и др.
Если вы хотите, чтобы в тексте странички появился символ ’;’ его надо написать так ’^;’. В принципе, префиксы ставить нужно не всегда, однако если вы их поставите — хуже не будет ;)

…method of MAIN (MAIN) accepts minimum XX parameter(s)…
Это означает, что вы вызываете оператор и пытаетесь передать ему меньше параметров, чем тот требует для своего функционирования. Очень часто такая ошибка происходит, когда вы между скобками, разделяющими параметры, ставите пробелы/переводы строк.

…method of MAIN (MAIN) accepts maximum XX parameter(s)…
Это означает, что вы вызываете метод, и пытаетесь передать ему больше параметров, чем тот может принять. Очень часто такая ошибка происходит, когда вы передаете в метод строку, содержащую спецсимволы, вероятно, символ «точка с запятой», не предварив её символом «птичка». При этом парсер воспринимает этот символ как разделитель передаваемых в метод параметров.

…method_frame may not be overwritten with table/date/hash, store it to variable instead…
Производится попытка добавить в тело страницы объект, который не может быть выведен парсером. Например, если написать в чистом поле ^date::now[] то получим такую ошибку. Чтобы вывести дату нужно сделать примерно следующее:
$now[^date::now[]]
^now.sql-string[]
Аналогично с объектами таблица, хеш и т.д.

…no $MAIN:CLASS_PATH were specified…
Вы пытаетесь использовать @USE или ^use[] но не задали переменную $MAIN:CLASS_PATH и парсер не знает, где искать классы, которые вы пытаетесь подключить. Подробности в документации.
Одна из возможных причин: переменная $MAIN:CLASS_PATH определена в конфигурационном auto.p, однако по каким-либо причинам на вашей системе он не выполняется. В поиске данной проблемы вам может помочь тестовый документ, скачанный из соответствующего раздела.
Другая возможная причина: вы пытаетесь подключить классы раньше, чем определили переменную $MAIN:CLASS_PATH. Такое обязательно произойдет если вы в корневом auto.p будете подключать дополнительные файлы в @USE, а определять упоминаемую переменную будете в методе @auto[], который выполняется после @USE.

…not found along MAIN:CLASS_PATH…
Файл с операторами или классами, которые вы пытаетесь подключить через @USE или ^use[] не найден по путям, указанным в переменной $MAIN:CLASS_PATH.
Часто проблема имеет место быть, если после имени файла в @USE закрался пробел/символ табуляции.
Также бывает, что после @USE и списка модулей забывают объявить метод и начинают писать код страницы, подразумевая, что это будет @main[]

…$SQL:drivers table must be defined…
Не настроен или отсутствует конфигурационный auto.p (это тот, который у cgi версии лежит рядом с исполняемым файлом парсера). Для простой проверки скачайте из соответствующего раздела тестовый документ, распакуйте его в веб пространство вашего сайта и обратитесь к нему из броузера.
Для того, чтобы данный файл смог все проверить, вам будет необходимо отредактировать конфигурационный auto.p и указать абсолютный путь в $confdir.

…driver failed to initialize client library '/path/to/libparser3mysql.so'…
libparser3mysql.so это не клиентская библиотека MySQL, а драйвер парсера. Вам в таблице драйверов нужно указать путь к этому драйверу и путь к клиентской библиотеке libmysqlclient.so. Местоположение драйвера вам известно (вы его сами копировали на сервер), а местоположение клиентской библиотеки вам может подсказать администратор вашего сервера если оно отличается от общепринятого.

…driver failed to initialize client library '/path/to/libmysqlclient.so'…
Попытка парсера обратиться к клиентской библиотеке SQL сервера libmysqlclient.so не увенчалась успехом. Вам нужно узнать у вашего системного администратора полный дисковый путь к этому драйверу и прописать его в таблицу $SQL:drivers в главном конфигурационном файле.

…driver implements API version 0xXXXX not equal to 0xYYYY…
Версия установленного и требуемого парсером драйвера (например libparser3mysql.so) не совпадают.
Причина может быть в том, что вы перешли с одной версии парсера на другую, но не обновили драйвер базы данных.

…undefined protocol 'XYZ'… (например 'mysql')
В главном конфигурационном файле (auto.p который находится рядом с парсером) не определен протокол, который вы пытаетесь использовать в операторе ^connect[>>тут<<]{код}

…outside of 'connect' operator…
Происходит попытка выполнить SQL запрос (^table::sql{}, ^int:sql{} и др.) вне оператора для подключения к БД ^connect[строка подключения]{запросы тут}.

…transcodeFromUTF8 error…
Тот кто настраивал вам parser или совсем не положил предлагаемый конфигурационный файл, или испортил его.
По-умолчанию, если $request:charset не задан (сейчас подходящий момент посмотреть в документацию) он равен UTF-8.
Parser’у не объяснили, в какой кодировке его документы ($request:charset), и он считает, что они в UTF-8.
Соответственно, если попросить его перекодировать из UTF-8 в windows-1251 (определив $response:charset), задав на входе текст в windows-1251, он честно возмутится.
Подобное может случиться если по каким либо причинам парсер не считывает конфигурационный auto.p, что можно проверить разместив в последнем ^throw[check;] или проанализировав в корневом auto.p какие-либо настройки, заданные в конфигурационном файле.

…'USE ' invalid special name. valid names are 'CLASS', 'USE' and 'BASE'…
После @USE закрался невидимый символ пробела/табуляции, который можно заметить, если приглядеться к тексту в первых одинарных кавычках. Удалите его, сразу после @USE должен быть символ перевода строки.

…endless loop detected…
Подобное сообщение появляется, если парсер обнаруживает очень длинный цикл. Например, если вы напишите конструкцию ^while(1){что-то} то будет подобное сообщение об ошибке. Кроме того, если вы сделаете большой цикл for или menu в котором будет более 20000 итераций, то тоже увидите подобное сообщение.

…call canceled - endless recursion detected…
Подобное сообщение появляется, если парсеру кажется, что код зациклился. Очень часто причиной может быть некорректная или очень глубокая рекурсия (более 1000 вызовов).

…SIGPIPE received. …
Такие записи появляются в parser3.log, при этом вроде все работает нормально. Что это означает?
Когда ответ от CGI-скрипта больше клиенту веб-сервера не нужен, например пользователь нажал кнопку stop, или потерялась связь, веб-сервер посылает скрипту сигнал «послушай, тут твой output больше никому не нужен». В версиях parser до 3.0.0006 этот сигнал специально не обрабатывался, и происходила его обработка по-умолчанию = убивание процесса посередине его работы [исключение составлял parser, соединившийся с oracle, там oracle библиотека включала игнорирование этого сигнала].
Это нехорошо, что нас убивали, и мы ничего не могли аккуратно закрыть.

С версии 3.0.0007 parser отлавливает этот сигнал и создаёт ошибку «parser.interrupted».

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

…post_size(XX) != content_length(YY)…
Ошибка означает следующее: от броузера посетителя на сервер пришёл POST запрос, в заголовке которого написано content-length:YY однако попытки считать это количество байт из stdin CGI процесса не увенчались успехом — было считано только XX байт.

Если подобная ошибка изредка встречается в parser.log, то можно просто не обращать на неё внимания, возможно в процессе POST-а данных от посетителя с нестабильным соединением произошел его разрыв и до сервера просто не дошла часть данных. Однако если каждый POST вызывает эту ошибку то проблема с настройками сервера.

…posted content_length(XXXX) > max_post_size(YYYY)…
Кто-то через форму на вашем сайте попытался закачать на сервер файл размером XXXX байт, в то время как у вас в главном конфигурационном файле указано, что серверу разрешено принимать файлы с максимальным размером YYYY байт.

…unknown mode, must be 'append'…
Обычно такая ошибка возникает когда вы записываете содержимое переменной на диск и думаете что переменная содержит файл, а на самом деле в переменной — строка (например забыли написать нужный enctype у формы и пытаетесь загрузить файл на сервер). Для решения проблемы просто сделайте перед записью проверку на тип переменной.

Дело в том что и у строки и у файла есть метод save, но он принимает разные параметры.

…invalid HTTP response status…
Вы попытались выполнить ^file::load[http://сайт/документ] и удаленный сервер в заголовке ответа вернул статус не равный 200, что для парсера является ошибкой. Если вам нужно иное поведение парсера и вы желаете самостоятельно разобраться с ответом укажите в параметрах $.any-status(1) как сказано в документации.

…out of memory…
Вашему коду для выполнения потребовалось памяти больше, чем ему позволил занимать системный администратор. Для решения этой проблемы вам потребуется оптимизировать код (убрать SELECT *, не загружать большие объемы данных, периодически обнулять переменные и выполнять ^memory:compact[], изменить логику работы кода) или попросить вашего администратора увеличить лимит памяти процессу.

Для поиска узкого места в коде вы можете воспользоваться методом @run_time[] из полезных пользовательских операторов.

…exception in request exception handler…
Данная ошибка означает, что вы допустили ошибку в методе @unhandled_exception[], который как раз и должен сообщать об ошибках. PAF утверждает, что начиная с версии 3.1.4 даже если вы допустите ошибку в этом методе парсер все равно внятно о ней сообщит.

У меня парсер назначен обработчиком файлов с расширением html, в .htaccess есть инструкция ErrorDocument 404 /404.html. Однако если я набираю в строке броузера путь к несуществующему файлу с расширением html, то вместо того, чтобы увидеть файл /404.html я вижу сообщение парсера об ошибке. Файлы с другими расширениями отрабатывают нормально. Как быть?
Вы всегда можете перехватить исключение парсера "file.missing" и сами отобразить вместо несуществующего документа документ /404.html. Можно изменить метод @unhandled_exception например так:

@unhandled_exception[exception;stack]
^if(^env:REMOTE_ADDR.match[^^IP адрес вас как разработчика]){
	^unhandled_exception_debug[$exception;$stack]
}{
	^if($exception.type eq "file.missing"){
		^rem{*** если нет файла то делаем внутренний ***}
		^rem{*** редирект на страницу с 404 ошибкой ***}
		^rem{*** не забывая написать в ней $response:status(404) ***}
		$response:location[/404.html]
	}{
		^unhandled_exception_release[$exception;$stack]
	}
}