, когда я использовал внешнюю библиотеку, я был удивлен, увидев, что console.log(err)
не вывел то, что я считал полной трассировкой стека. другими словами, он не выводил ту часть моего кода, где произошла ошибка.
Вот пример. Я использую внешнюю библиотеку. я ожидаю, что это вызовет ошибку, когда я позвоню container.inspect()
. я обрабатываю обещание container.inspect()
возвратов и регистрирую все ошибки, которые я получаю, с console.log(err)
и console.trace(err)
const Docker = require('dockerode');
const docker = new Docker();
const container = docker.getContainer('38f5bb6d7fd1');
container.inspect()
.then(data => {
console.log(data);
})
.catch(err => {
console.log("-----------------");
console.log("USING CONSOLE.LOG(ERR)")
console.log(err);
console.log("USING CONSOLE.TRACE(ERR)");
console.trace(err);
});
мой вывод журнала следующий
-----------------
USING CONSOLE.LOG(ERR)
Error: (HTTP code 404) no such container - No such container: 38f5bb6d7fd1
at /home/edwin/docs/node_modules/docker-modem/lib/modem.js:294:17
at getCause (/home/edwin/docs/node_modules/docker-modem/lib/modem.js:324:7)
at Modem.buildPayload (/home/edwin/docs/node_modules/docker-modem/lib/modem.js:293:5)
at IncomingMessage.<anonymous> (/home/edwin/docs/node_modules/docker-modem/lib/modem.js:268:14)
at IncomingMessage.emit (events.js:215:7)
at endReadableNT (_stream_readable.js:1198:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21) {
reason: 'no such container',
statusCode: 404,
json: { message: 'No such container: 38f5bb6d7fd1' }
}
USING CONSOLE.TRACE(ERR)
Trace: Error: (HTTP code 404) no such container - No such container: 38f5bb6d7fd1
at /home/edwin/docs/node_modules/docker-modem/lib/modem.js:294:17
at getCause (/home/edwin/docs/node_modules/docker-modem/lib/modem.js:324:7)
at Modem.buildPayload (/home/edwin/docs/node_modules/docker-modem/lib/modem.js:293:5)
at IncomingMessage.<anonymous> (/home/edwin/docs/node_modules/docker-modem/lib/modem.js:268:14)
at IncomingMessage.emit (events.js:215:7)
at endReadableNT (_stream_readable.js:1198:12)
at processTicksAndRejections (internal/process/task_queues.js:80:21) {
reason: 'no such container',
statusCode: 404,
json: { message: 'No such container: 38f5bb6d7fd1' }
}
at /home/edwin/docs/help.js:15:13
at processTicksAndRejections (internal/process/task_queues.js:93:5)
a. Когда я использую console.trace(err)
, я могу четко видеть строку и номер символа, где я позвонил console.trace()
(at /home/edwin/docs/help.js:15:13
).
b .. когда я использую console.log(err)
, я не могу увидеть строку и номер символа, где я позвонил console.log()
.
, и я ожидаю этого. однако
c .. когда я использую оба console.trace(err)
и console.log(err)
, i не может увидеть строку и номер символа функциия позвонил, что в итоге создал ошибку (container.inspect()
). логи не говорят мне, что вызов container.inspect()
закончился с ошибкой. (Мне бы очень хотелось, чтобы где-то в журнале было зафиксировано следующее: "at /home/edwin/docs/help.js:6:13
", где 6
- это номер строки container.inspect()
. Я посмотрел на specwg console spec , но могЯ не могу найти объяснение этому поведению.
Мой вопрос заключается в следующем: как я узнаю, что вызов container.inspect()
(в строке 6, символ 13) фактически вызвал ошибку - в большой кодовой базе, вызвав console.log(err)
(или console.error(err)
) не скажет мне. звонящий console.trace(err)
не не скажет мне тоже. он только скажет мне номер линии, с которой я позвоню console.trace(err)
. console.trace(err)
дает мне чрезвычайно полезную информацию относительно console.log(err)
, но все же не то, что я хочу (как я объяснил в (c ..)). Было бы использование отладчика единственным практическим способом выяснить, откуда возникла эта ошибка