Ошибка при использовании метода GetValue()

Question

Я унаследовал службу WCF, которая действует как кеш-файл (каждый файл представляет результаты запроса стороннему API). На данный момент, если файл не существует, код создает новый запрос для создания данных, а также создает исключение для кода клиента.

Я думаю, что идея заключается в том, что клиенты вернутся, чтобы снова запросить файл, и к тому времени он будет доступен им (для создания файла требуется несколько секунд).

Я думаю, что здесь есть запах кода, и я должен переписать эту часть. На данный момент исключение получает пойманное и пузырящееся через пару методов. Я думаю, что я должен установить у источника, существует ли файл и передавать эту информацию в стек вызовов.

В интерфейсе WCF Я в настоящее время метода GetValue(), хотя есть два варианта, я думаю, что я мог бы использовать, чтобы заменить его:

1. возвращения null, если файл не существует.
2. Используйте bool TryGetValue(string key, out string value) метод

Кто-нибудь есть какие-либо предпочтения/рекомендации?

Благодаря

Answer 1

«TryGet» подход немного более явным. При использовании метода null-return вы должны документировать, что метод возвращает null по той или иной причине, и для этого требуется, чтобы разработчики прочитали документацию. Как мы все знаем, у некоторых людей есть аллергия на чтение документации.

Еще одно преимущество подхода «TryGet» заключается в том, что вы можете использовать перечисление, а не bool, чтобы дать еще больше информации вызывающему о том, почему и как метод не удалось (или преуспел).

Определение исключения из исключения: когда участник действия не может выполнить свою задачу, член должен исключить исключение. Исключение означает, что участник действия не смог выполнить задачу, которую он должен был выполнить, как указано по его названию. Мой вопрос в том, должен ли я держать метод GetValue доступным для клиента и вызывать ошибку, когда данные недоступны или удалить их и заменить на TryGetValue()? определение

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

В вашем дизайне вы ожидаете, что ценность будет недоступна, как само собой разумеющееся; это означает, что не является исключительной ситуацией, когда значение недоступно. я поэтому использовал только TryGet ... рисунок.

Но, честно говоря, я бы пошел совсем по другому подходу. Предположим, что кто-то пытается этот подход:

while (!TryGetValue(key, out value)) {} 

или:

SomeType value; 
bool flag = false; 
while (!flag) 
{ 
    try 
    { 
     value = GetValue(key); 
     flag = true; 
    } 
    catch {} 
} 

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