Я использую маршруты API fetch() для заполнения страницы панели управления данными. Во время разработки я принял план использовать блоки try {} catch {} для обработки и перехвата ошибок, а затем передавать сообщение об ошибке в локальный файл журнала. Тогда сервер ответит {ok:false}, что является универсальным способом сказать «нехорошо». Это точно так же, как и другие условия, например отсутствие входа в систему, что делает рабочий сервер очень непрозрачным.
Вот пример:
import { logError } from 'errorLogger';
import { getEncryptedSessionCookie, smartSessionSave } from 'authHandler';
export async function GET(req) {
try {
const session = await getEncryptedSessionCookie();
// Perform a series of tasks.
await smartSessionSave(session);
return Response.json(ret);
} catch (err) {
logError('/api/happyLittleRoute',err);
return Response.json({ok:false});
}
В любом случае, теперь, когда я тестирую сервер Next в производстве, я вижу, что при сборке приложения я получаю такую ошибку:
/api/happyLittleRoute Error: Dynamic server usage: Page couldn't be rendered statically because it used `cookies`. See more info here: https://nextjs.org/docs/messages/dynamic-server-error
Мне удалось устранить ошибку, удалив блок try/catch, который указывает на то, что он является виновником. Однако в результате я не получаю запись ошибок в файл, как хотелось бы с помощью функции logError(). Кроме того, без блока try/catch сервер в конечном итоге возвращает ошибки сервера, что не соответствует моему требованию, чтобы сервер всегда выглядел так, как будто он работает нормально для внешнего мира.
Я искал на сайте nextjs.org информацию о том, как создать обработчик ошибок, но документация описывает только то, как создать что-то для обработки ошибок при рендеринге страницы.
https://nextjs.org/docs/app/api-reference/file-conventions/error
Есть ли правильный способ создать границу ошибки для всех экспортированных функций GET() и POST(), чтобы они вели себя как показанный выше блок catch, который по-прежнему хорошо строится и работает в рабочей среде?





Обновлять:
Хотя я не нашел ответа на приведенное выше решение, вместо этого я устранил блоки try в корне сегментов маршрута и вместо этого рассматриваю необработанные ошибки как недостаток дизайна.
Одна распространенная практика, которую я взял на вооружение, — это возврат объектов из библиотечных функций, которые я пишу, с объектом ok для обозначения статуса и данными для обозначения возврата.
myDatabaseCall.js
export async function getUserList(authObj) {
try {
// do all the database stuff here
return {ok: true, data: arrayOfThings}
} catch (err) {
// handle custom logging for production.
return {ok:false}
}
}
маршрут.js
import getUserList from './myDatabaseCall.js';
import performAuthCheck from './myAuthCheck.js'; //not shown
export async function GET(req) {
let auth = await performAuthCheck(req,'administrator');
if (auth.ok === false) {
return {ok:false}
}
let userList = getUserList(auth.data);
if (userList.ok === false) {
return {ok:false}
}
return {ok:true, data:userList.data};
}
Он немного более повторяющийся, но ответ серверной части остается непрозрачным для ошибок, а интерфейсной части также легко справиться с обработкой ответа.