- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
try
{
await storageClient.DownloadObjectAsync(Bucket, fileName, stream).ConfigureAwait(false);
}
catch(Exception ex)
{
throw new FileStorageException($"File '{fileName}' not found in a bucket '{Bucket}'", ex) { StatusCode = StatusCodes.Status404NotFound };
}
Евреев туда не пустят.
А вот ловля «Exception ex» — это говно, да.
Писать в лог нужно далеко не всегда, важен коньтекст. Если этот код — из либы для работы с какой-то сетевой ФС, то выбрасывания подробного, семантически верного, исключения вполне достаточно, либе совершенно не обязательно срать в лог, это оверинжиниринг. В лог писать должен тот код, который этот самый FileStorageException поймает.
>>> в эксепшене создается еще один эксепшн
нет.
catch(HttpException ex) when (ex.StatusCode == 403)
[/сode]
А шо, так можно?
https://ideone.com/zXstg3
Сейчас так модно делать.
* Вполне ожидаемые проблемы, являющиеся частью бизнес-логики. Например ввод неверного имени. Недоступность сети может быть такой проблемой, а может и не быть: зависит от того, что за приложение. В Java это Checkeed Exceptions. В нормальных языках это монада типа Result.
* Пиздецы. NPE/NRE. OutOfMemory, ClassNotFound (если конечно это не введенный пользователем класс). Такие ошибки не надо ловить никогда (кроме как если ты пишешь сервер приложений). Их надо рассматривать как DivisionByZero, и схлопывать приложение.
Надо ли показывать пиздецы пользователю?
В веб-приложении однозначно НЕ надо (если ты не пыхапист), но их надо писать в лог.
В десктопном надо (иначе как он поймет, что случилось?), но можно и их тоже записать в лог, чтобы их потом показали разрабам.
В идеальном мире исключения используются только для пиздецов, а для бизнес-логики есть другие инструменты. К сожалению в жабе, например, это единственный способ внятно вернуть ошибку так, чтобы клиент класса её проверил.
ex тоже в camel case
а StatusCode в pascal case.
Это у шарперов норм?
Переменные пишутся с маленькой буквы. Филды классов, имена функций и классов -- с большой.
Впрочем, это же Visual BRACIS...
Зачем? Зачем? Чем они от переменных отличаются?
На самом деле я наврал
С большой буквы пишутся проперти
Проперти это по сути аксессоры и мутаторы
Для приватных строгого соглашения нет, и вот их как правило пишут со строчной, как обычную переменную; некоторые ещё андерскор впереди добавляют.
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions
Публичные филды не нужны, когда есть сахар set;get;. Лучше сразу делать проперти, чтобы потом не сломалось abi, когшда решиш инкапсулировать
Неужели у storageClient нет метода "проверить наличие файла"?
Судя по https://googleapis.github.io/google-cloud-dotnet/docs/Google.Cloud.Storage.V1/api/Google.Cloud.Storage.V1.StorageClient.ht ml — именно такого нет, разве что GetObject().
Впрочем, он и не нужен: в распределённых приложениях паттерн «проверить наличие, потом использовать» — априори говно.
Если эта хуйня упакована в storageClient, можно было бы создавать какой-нибудь StorageClientInstance, который бы под капотом делал один запрос, но поддерживал бы оба метода, храня в себе состояние этого запроса. Разве получилось бы хуево?
скорее всего он не осилил связаться с сетевой карточкой, а при попытке открыть несуществующее устройство (и вообще любой абъект в object manager) можно получить тот самый FILE_NOT_FOUND
не ошибся