Лучше бросать NotSupportedException внутри или снаружи задачи?

Question

У нас есть система нисходящего потока, система ERP, которая может выставлять свои таблицы через SOAP. Веб-служба, которую он публикует, обычно имеет методы создания, обновления и удаления. Затем мы создаем прокси-сервер на нашем конце с помощью svcutil, включая методы async. Наконец, мы помещаем ACL перед этим для взаимодействия с другими системами.

Мы также только что обнаружили важную информацию об инварианте - стоимость для элементов не может быть обновлена ​​ничем иным, чем самой системой ERP. Однако действительно немой API позволит потребителям сделать это.

Моя идея обойти это подклассы прокси-сервера WCF и иметь явные реализации для обновления, которые выкидывают NotSupportedException. Нет, это не помешает разработчику генерировать собственный прокси-сервер и делать это. Но по крайней мере мы можем гарантировать, что это не может произойти, когда мы пройдем через наш ACL.

Update_Result Item_Port.Update(Update request) 
    { 
     throw new NotSupportedException(); 
    } 

Для асинхронных методов, я мог либо сделать

Task<Update_Result> Item_Port.UpdateAsync(Update request) 
    { 
     throw new NotSupportedException(); 
    } 

ИЛИ

Task<Update_Result> Item_Port.UpdateAsync(Update request) 
    { 
     return Task.Factory.StartNew<Update_Result>(() => 
     { 
      throw new NotSupportedException(); 
     }); 
    } 

С точкой зрения асинхронного, что один является более "правильным?

Answer 1

У двух будет другое поведение.

В первом случае вызывающий API будет получать NotSupportedException сразу после вызова этого метода.

В вашем втором случае вызывающий абонент получит неисправный Task<T> (или тот, который будет обвинён вскоре после вызова). Это вызовет исключение в продолжении задачи или когда значение задачи будет извлечено (через task.Result).

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