2016-02-23 2 views
4

В моем C приложении # Я инициализация CloudTable экземпляра с помощью следующего кода:Как игнорировать ресурсы хранилища таблиц не найдены исключения без использования контекстов таблицы?

 var account = CloudStorageAccount.Parse(connectionString); 
     var client = account.CreateCloudTableClient(); 
     client.DefaultRequestOptions.RetryPolicy = new LinearRetry(); 

     var table = client.GetTableReference(tableName); 
     table.CreateIfNotExists(); 

     return table; 

Когда я выполнить операцию, чтобы получить запись из хранилища таблиц, я обычно делаю что-то вроде:

var realEntity = _table.Value.ExecuteQuery(StreamKeyConfigurationEntity.CreateQuery(calculatedPartitionKey, calculatedRowKey)) 
         .SingleOrDefault(); 

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

Хорошая новость, я наткнулся на несколько статей (например, this one, которые утверждают, что вы можете обойти эту проблему, установив IgnoreResourceNotFoundException свойство true.

Совершенных, за исключением того, что он использует TableContext не CloudTable. Это проблема становится intellisense явно говорит, что использовать пространство имен таблиц вместо пространства имен контекста, поскольку метод GetTableServiceContext() помечается как устаревший.

Есть ли какой-либо способ обхода игнорировать ресурс, не найденные исключения, поэтому мне не нужно обертывать все запросы в try/catch с использованием CloudTable материал?

+0

Что не так с try/catch? – Jacobr365

+0

Чтобы сделать это повсюду, добавьте шум и шаблон и, возможно, затмевайте другие 'StorageException', о которых мне может понадобиться знать. – KallDrexx

+0

Достаточно честный. Полагаю, я никогда не думал о попытке поймать мой код. Также вы можете просто проверить сообщение об исключении, если это 404, который вам неинтересен, и если он другой, просто бросайте его снова. – Jacobr365

ответ

0

Извините, но для библиотеки обычно опасно игнорировать некоторые исключения, которые возвращаются в соответствии с контрактом REST службы. Если у вас есть особые требования и вы хотите игнорировать исключения, вы должны использовать встроенные функции языка, которые позволяют это (а именно, try-catch).

+0

Я думаю, это объясняет, почему он был удален, хотя я не совсем уверен, что согласен с ним. Почему я должен заботиться о нем как о конечном пользователе, если он использует REST под капотом или нет, большую часть времени использует библиотеку для извлечения ресурсов Я бы ожидал нулевой или пустой список, если результаты не были возвращены, независимо от базовой реализации. – KallDrexx

+0

@KallDrexx Что вы подразумеваете под конечным пользователем? Для хранения таблиц конечным пользователем является человек, использующий API хранения таблиц. его приложения. Когда вы являетесь пользователем API, вы очень много заботитесь о реализации интерфейсов. Ваша реализация будет зависеть от этого. – Zee

+0

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