Ось цікавий психологічний момент на 11:45, де пан Сергій розповідає про "обгортання помилок" та на 12:30 каже що це допомогає потім при читанні логів. Ось в нас є мови для "швидкої" розробки, це коли ми щось пишемо за годину, кидаємо у прод. Потім разів 5 нас підіймають бо "undefined is not a function" і ми витрачаємо по декілька годин на усунення цієї проблеми. Є трішки кращі мови типу тієї Java, коли деякі перевірки робляться при процесі написання. Що довше, тож ми пишемо щось не году, а півтори але вже на будуть викликати не 5 разів а два тому що десь щось null або якесь невідоме виключення. Й далі йде наприклад Rust де ми кожна функція явно декларує що може піти не так і програміст має явно вказати що у якому випадку робити. Причому компілятор усе перевірить й буде голосно лаятися якщо десь щось не так. Тому ми вже на написання витрачаємо навіть 2 години але наш софт працює. Просто працює.
3:05 у сучасних мовах як раз відмовились від виключень тому що вони є goto. Які з ними проблеми: - ми не знаємо чи може функція мати помилку (або документація яка може застаріти та брехати або вручну повністю рекурсивно перевіряти що у функції робиться) - ми не знаємо як на вищіх рівнях робиться перехоплення виключення. Ось я працюю з якоюсь функцією foo й додаю нову залежність, яка викидає якийсь тип виключення. Що далі, мені вручну розбирати усі потоки виконання які можуть викликати цю foo та перевіряти у якому місці й як мені додати обробку нового типу виключення? Якщо виключення містить інформацію на підгрунті якої програма має прийняти рішення. Як це у Раст, який розроблявся як більш надійна мова: повертається тип Result який містить або вдалий результат або дані про помилку. Це зазначено у сигнатурі. Робота з Т неможлива без перевірки Е. Є оператор швидкого поширення помилки '?'. Напрмклад у нашій foo() викликається кілька різних функцій у яких щось може піти не так та які повертатимуть Result та Result. А наша функція повертає Result. У такому випадку ми окремо прописуємо логіку перетвореня одного типу помилки не інший не забруднюючи на основний код. Зазвичай використовують якийсь enum (який може містити не лише дискрімінант але й дані; після енумів як у Расті мови де такого немає сприймаються як неповноцінні) який містить й базову помилку й якісь інші дані. Приблизно теж стосується null. У вас не буде проблем з null якщо у вашій мові нема null. Замість цього є Option яке не дозволяє звертвтися до Т без перевірки. А також якщо вже є Т - то там гарантовано буде Т, більше перевірок не потрібно. Програмування на Руст це як їзда по рельсах, просто рухаєшся вперед. У той час як більшість мов - це блукання у хащях.
Ех, а я на С програмую в ембедедіі нічого крім кодів повернення немає, ну хіба можна зробити функцію OnError з якої немає виходу крім перезавантаження пристрою і при помилці її завжди викликати.
2:10 зараз прийнято щоб можно було у сигнатурі функції позначити, чи буде мутувати аргумент переданий через посилання, а не як у якихось старих мовах про це мав би здогадуватися програміст.
Не згоден про checked exceptions. Тобто може воно у конкретній мові Java як і багато чого іншого зроблено через одно місце, але в чому проблема явно зазначити тип(и) можливих помилок? З таким же успіхом можно сказати що у чистому JS не пишеться явно тип аргумента й взагалі не вказується чи повертає функція шось тому що ця інформація - сміття та он у JS якось щось пишуть та нічого, воно навіть працює. Іноді. Ps 8:51 - а як програміст дізнається що може взагалі виникнути виключення, так які типи виключень можуть виникнути?
З таким же успіхом можна сказати не використовувати Either чи Result тощо. Це ж теж явна декларація про можливість помилки. Незадурюйте собі голову - кидайте просто Runtime Exception і надійтесь, що користувач вашого API десь у верхніх слоях напише try catch
Якось довелось в літературі прочитати порівняння, що обробка throw в Java - це як зупиняти автомобіль стовпом, замість використання гальм. Наскільки памʼятаю в ФП використовують Either без прокидування throw
в такому випадку прокидується Either. Виходить, що в обох випадках явним чином вказується, що метод може завершитися із помилкою. А далі кожен сам вибирає який синтаксис подобається
Объясните мне, как это работает: 1. Не используйте Проверяемые исключения, они всё равно будут обрабатываться в одном месте, все массово. 2. Создавайте для каждого слоя своё исключение, ещё лучше, если и их разделить по подкатегориям. А потом на каждом слое оборачивайте исключение в новое исключение используя контекстный вызов. Так как я узнаю какие ошибки я могу получить, если исключения не прописаны в сигнатуре метода? И если я один хрен их ловлю, чтобы обернуть и добавить в лог, то какой смысл их делать не проверяемыми и получить исход, когда обработку исключения забыли добавить? Полагаться на документацию нельзя, как говориться её всегда могут забыть обновить.
ну, ви теж порівняли Rust який досить молодий, і Java/C#, яким вже третій десяток пішов. В Rust на рівні дизайну мови вже пофіксали проблеми C з поінтерами і пам'яттю і проблеми ООП мов із exceptions. Все найкраще взяли і прийшли до функціонального підходу :)
@@nanvlad ну так давайте йти в ногу з часом, знайомитися з новими технологіями, підходами, парадигмами. Я про себе називаю Rust "пост-ооп мовою". А є люди які буквально вважають що Rust це "Низькорівнева мова з ручним керуванням пам'яттю як у С".
Ось цікавий психологічний момент на 11:45, де пан Сергій розповідає про "обгортання помилок" та на 12:30 каже що це допомогає потім при читанні логів.
Ось в нас є мови для "швидкої" розробки, це коли ми щось пишемо за годину, кидаємо у прод. Потім разів 5 нас підіймають бо "undefined is not a function" і ми витрачаємо по декілька годин на усунення цієї проблеми.
Є трішки кращі мови типу тієї Java, коли деякі перевірки робляться при процесі написання. Що довше, тож ми пишемо щось не году, а півтори але вже на будуть викликати не 5 разів а два тому що десь щось null або якесь невідоме виключення.
Й далі йде наприклад Rust де ми кожна функція явно декларує що може піти не так і програміст має явно вказати що у якому випадку робити. Причому компілятор усе перевірить й буде голосно лаятися якщо десь щось не так. Тому ми вже на написання витрачаємо навіть 2 години але наш софт працює. Просто працює.
3:05 у сучасних мовах як раз відмовились від виключень тому що вони є goto. Які з ними проблеми:
- ми не знаємо чи може функція мати помилку (або документація яка може застаріти та брехати або вручну повністю рекурсивно перевіряти що у функції робиться)
- ми не знаємо як на вищіх рівнях робиться перехоплення виключення. Ось я працюю з якоюсь функцією foo й додаю нову залежність, яка викидає якийсь тип виключення. Що далі, мені вручну розбирати усі потоки виконання які можуть викликати цю foo та перевіряти у якому місці й як мені додати обробку нового типу виключення? Якщо виключення містить інформацію на підгрунті якої програма має прийняти рішення.
Як це у Раст, який розроблявся як більш надійна мова: повертається тип Result який містить або вдалий результат або дані про помилку. Це зазначено у сигнатурі. Робота з Т неможлива без перевірки Е. Є оператор швидкого поширення помилки '?'. Напрмклад у нашій foo() викликається кілька різних функцій у яких щось може піти не так та які повертатимуть Result та Result. А наша функція повертає Result. У такому випадку ми окремо прописуємо логіку перетвореня одного типу помилки не інший не забруднюючи на основний код. Зазвичай використовують якийсь enum (який може містити не лише дискрімінант але й дані; після енумів як у Расті мови де такого немає сприймаються як неповноцінні) який містить й базову помилку й якісь інші дані.
Приблизно теж стосується null. У вас не буде проблем з null якщо у вашій мові нема null. Замість цього є Option яке не дозволяє звертвтися до Т без перевірки. А також якщо вже є Т - то там гарантовано буде Т, більше перевірок не потрібно.
Програмування на Руст це як їзда по рельсах, просто рухаєшся вперед. У той час як більшість мов - це блукання у хащях.
дяка за відео, вподобайка і коментар задля популяризації каналу
Допомагаймо ЗСУ!
13:04 * не використовуйте мови у яких є null.
Ех, а я на С програмую в ембедедіі нічого крім кодів повернення немає, ну хіба можна зробити функцію OnError з якої немає виходу крім перезавантаження пристрою і при помилці її завжди викликати.
вражаєте. Вже другий ролик за тиждень.
2:10 зараз прийнято щоб можно було у сигнатурі функції позначити, чи буде мутувати аргумент переданий через посилання, а не як у якихось старих мовах про це мав би здогадуватися програміст.
Кумедно дивитись як Golang розробнику
Result, Either, Kotlin Arrow Raise DSL
Не згоден про checked exceptions. Тобто може воно у конкретній мові Java як і багато чого іншого зроблено через одно місце, але в чому проблема явно зазначити тип(и) можливих помилок? З таким же успіхом можно сказати що у чистому JS не пишеться явно тип аргумента й взагалі не вказується чи повертає функція шось тому що ця інформація - сміття та он у JS якось щось пишуть та нічого, воно навіть працює. Іноді.
Ps 8:51 - а як програміст дізнається що може взагалі виникнути виключення, так які типи виключень можуть виникнути?
З таким же успіхом можна сказати не використовувати Either чи Result тощо. Це ж теж явна декларація про можливість помилки. Незадурюйте собі голову - кидайте просто Runtime Exception і надійтесь, що користувач вашого API десь у верхніх слоях напише try catch
Якось довелось в літературі прочитати порівняння, що обробка throw в Java - це як зупиняти автомобіль стовпом, замість використання гальм. Наскільки памʼятаю в ФП використовують Either без прокидування throw
в такому випадку прокидується Either. Виходить, що в обох випадках явним чином вказується, що метод може завершитися із помилкою. А далі кожен сам вибирає який синтаксис подобається
Объясните мне, как это работает:
1. Не используйте Проверяемые исключения, они всё равно будут обрабатываться в одном месте, все массово.
2. Создавайте для каждого слоя своё исключение, ещё лучше, если и их разделить по подкатегориям. А потом на каждом слое оборачивайте исключение в новое исключение используя контекстный вызов.
Так как я узнаю какие ошибки я могу получить, если исключения не прописаны в сигнатуре метода? И если я один хрен их ловлю, чтобы обернуть и добавить в лог, то какой смысл их делать не проверяемыми и получить исход, когда обработку исключения забыли добавить?
Полагаться на документацию нельзя, как говориться её всегда могут забыть обновить.
Після того як перейшов на Rust підходи як у відео виглядають як недолугі вирішення штучно створенних хибними мовами проблем.
ну, ви теж порівняли Rust який досить молодий, і Java/C#, яким вже третій десяток пішов. В Rust на рівні дизайну мови вже пофіксали проблеми C з поінтерами і пам'яттю і проблеми ООП мов із exceptions. Все найкраще взяли і прийшли до функціонального підходу :)
@@nanvlad ну так давайте йти в ногу з часом, знайомитися з новими технологіями, підходами, парадигмами. Я про себе називаю Rust "пост-ооп мовою". А є люди які буквально вважають що Rust це "Низькорівнева мова з ручним керуванням пам'яттю як у С".