Использование обещаний CommonJS: отказ от исключений

Question

У меня есть функция, downloadAsync(), которая возвращает обещание CommonJS (с использованием Q). Он может потерпеть неудачу двумя способами:

1. Файл уже может быть загружен, и в этом случае мы сразу узнаем.
2. Процесс загрузки может завершиться неудачей, и в этом случае мы знаем некоторое время спустя.

В случае (1), поскольку я знаю, прежде чем что-либо произойдет асинхронно, я мог бы сделать исключение. В случае (2) мне придется отказаться от обещания.

Мой вопрос в том, должен ли мой API быть единообразным и всегда сигнализировать об ошибке, отвергая обещание? Или я должен делать исключения для сразу определяемых недействительных состояний? В качестве другого примера, если пользователь передал мне неверный аргумент, было бы гораздо разумнее ошибиться, чем отклонить обещание.

Некоторая ясность в отношении того, как «исключительное» обещание отклонения действительно было бы здорово; используется ли там карта «один-к-одному» с практикой использования исключений или мы используем ее для не исключительного сбоя?

Answer 1

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

Вот пример.

if (fallback === undefined) { 
    fallback = function (op) { 
     return reject("Promise does not support operation: " + op); 
    }; 
} 

Когда Q представлен недопустимым вводом, Q вызывает резольвер с объектом отклонения. Поэтому вы можете быть оправданы тем, что ваш API ведет себя аналогично, вместо того, чтобы пытаться изменить поведение базовой библиотеки.

Плюс, посмотрите на это с точки зрения любого, кто использует ваш API. Они хотят разрабатывать и поддерживать два пути обработки исключений, или один?

Answer 2

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

Единственная причина, по которой можно сделать различие между исключениями и исключениями, было бы, если бы обещание было действительно важным для вашего приложения, поскольку я не подумайте, что вы можете исключить исключение из внутреннего вызова. (Опять же, это Доджо обещает, а не на 100% уверен, как твоя работа ...)