TL; DR - Ні , ви не повинні просто ігнорувати винятки тихо.
Давайте розглянемо припущення.
Я навчився вірити, що багато рішень у .NET приймалися людьми, які дійсно знають, що роблять, і зазвичай є дуже вагома причина для того, що вони вирішують. Але цей рятується від мене.
У MS є кілька справді геніальних людей на персоналі, без сумніву. У них також є ряд керівників та керівників, які ... незрозумілі, і які послідовно приймають погані рішення. Як би ми не хотіли вірити казці вченого технічно кмітливого, що керує розробкою продукту, реальність набагато похмуріша.
Моя думка, якщо ваш інстинкт говорить вам, що щось може бути не так, то є хороший шанс (і минулий прецедент), що він неправильний.
Як поводитися з винятками в цьому випадку - це рішення людських факторів, а не технічне рішення. Виключення - помилка. Повідомлення про помилку, навіть якщо вона неформатована, надає важливу інформацію кінцевому користувачеві. А саме, щось пішло не так.
Розглянемо цю гіпотетичну розмову між кінцевим користувачем та розробником.
Користувач: Додаток зламано.
Dev: Що зламано?
Користувач: Не знаю, натискаю на кнопку, і нічого не відбувається.
Dev: Що ти означає, що нічим не буває?
Користувач: Подивіться, я клацаю, чекаю, і я чекаю, і я чекаю, і нічого ... це, очевидно, зламано.
Наш бідний, на щастя гіпотетичний розробник, тепер повинен з'ясувати, що пішло не так у ланцюзі подій. Де це було?
Повідомлення обробника події -> Повсякденне обробляння події -> Метод, ініційований обробником -> початок асинхронного виклику -> 7 шарів мережі OSI -> фізична передача -> резервне копіювання 7 шарів мережі OSI -> послуга отримання -> метод, викликаний службою -> ... -> повернути відповідь, надісланий службою -> .... -> отримання асинхроніму -> обробка відповіді на асинхрон -> ...
І зауважте, що я описав кілька потенційних помилок.
Звертаючись до деяких основних припущень, я думаю, стає зрозумілішим, чому тихо придушення винятків є поганою ідеєю. Виняток та пов’язане з ним повідомлення про помилку є ключовим показником для користувачів, що щось пішло не так. Навіть якщо повідомлення не має сенсу для кінцевого користувача, вбудована інформація може бути корисною для розробника для розуміння того, що пішло не так. Якщо їм пощастить, повідомлення навіть призведе до рішення.
Я думаю, що проблема тут полягає в тому, що неправильно оброблений виняток призведе до збою вашої програми. Пригнічуючи винятки, програма не вийде з ладу. Існує певна обґрунтованість цього, хоча з точки зору асинхронізації - дозволити програмі продовжувати працювати під час отримання даних. Не так вже й багато логічного розширення, якщо говорити про те, що якщо ви можете продовжувати працювати, очікуючи на результати, то невдача у пошуку також не повинна руйнувати додаток - виклик async неявно оголошується як недостатньо важливий для завершення роботи програми.
Отже, це рішення, але це вирішення неправильної проблеми. Не потрібно багато зусиль, щоб забезпечити обгортку для обробки винятків, щоб програма могла продовжувати працювати. Виняток - це вилучення, повідомлення про помилку, викинуте на екран або ввійшли в систему, і програмі дозволяється продовжувати працювати. Придушення винятку означає, що ігнорування помилок буде А-ОК, і тестування гарантує, що винятки ніколи не потраплять у поле.
Тож моя кінцева оцінка полягає в тому, що це наполовину спроба вирішити проблему, створену шляхом підштовхування людей до асинхронної моделі, коли вони не були готові перекласти своє мислення на цей підхід.