Хей, чакай, какъв е нещастният път? Добре, нека започнем отначало, щастливият път е сценарий по подразбиране, не включващ изключителни или грешки, така че нещастният пътса всички други сценарии, при които възникват извънредни условия или условия на грешка.
Тази история ще се опита да събере няколко концепции като Either и Validated в REST приложение.
- Моделиране на нещастния път (изключения / грешки)
- Обработка на грешки и съпоставяне към HTTP статус кодове
Предпоставки
- Основно разбиране на DataTypes, Kotlin & SpringBoot
Моделиране на нещастния път
„Като потребител искам да извлека резервации за даден продукт по идентификатор“
Имаме своя щастлив път, при който можем да отговорим на нашата заявка от потребител с резервация (зелени стрелки) и има 5 пътя, при които трябва да върнем съобщение за грешка, указващо, че не можем да върнем това, което са поискали.
Тези грешки са това, което в Java използвахме за „моделиране“ като изключения. Програмистът трябва да има подробни изключения, описващи всеки тип грешка, както всички сме правили в началото си, започвате да хвърляте new RuntimeException()което не казва нищо за грешката ( нещастен път) и когато това се случи в производството, просто трябва да отстраните грешки в кода си, за да разберете какво се е случило. След няколко удара по лицето започвате (надявам се :) ) да създавате персонализирани изключения и включително описания, които ви уведомяват за контекста на повредата с един поглед. На този етап сте ОК (от гледна точка на Java).
Но изключенията имат няколко недостатъка, възможно е изключение просто да бъде „загубено“ и ако документацията не е достатъчно добра, ще откриете някои от тях по време на изпълнение ›.‹
Тук можем да отидем по-далеч и да използваме типове данни и конвенции, за да подобрим този сценарий.
Типове данни на помощ: Either & Validated
Типът данни е абстракция, която капсулира кодиращ модел за многократна употреба. Тези решения имат канонична реализация, която е обобщена за всички възможни употреби.
Предложението е, докато моделираме нашия сценарий за успех, да направим същото и за неуспехите. Как тогава да съобщим грешка? Като го направим изрично в типа данни, който връщаме.
Или се използва за прекъсване на изчисление при първата грешка, то съответства на логическото Или или + като алгебричен тип данни. Харесва ми да го мисля като кутия с две кофи: по конвенция лявата кофа се използва за запазване на Провала, а дясната кофа за Успеха. Тук можете да намерите наистина добра документация за този тип данни.
Има много документация с много примери за малки стъпки, отиваме директно към случай на използване в реалния свят. В нашия пример трябва да използваме външна услуга и да десериализираме нейното съдържание към нашия резервационен модел. Услугата връща списък с резервации, дори при търсене по ID.
Проверете какво сме направили, подписът на нашия метод fun get(pnr: String): Either‹BookingRetrievalError, Booking›казва, че ще върне Резервация (вдясно), когато всичко отива надясно и BookingRetrievalError (вляво) когато има грешка. Класът BookingRetrievalError моделира всички възможни повреди, така че да можете да се справите с всяка от тях, като избягвате всякаква изненада по време на изпълнение.
- BookingNotFound -› резервация с даден Pnr (id) не беше намерена
- SupplierFailure -› външен доставчик не успя да обработи нашата заявка
- UnexpectedFailure -› не знаехме какво се случва
Както можете да видите, няма да има изненада по време на изпълнение, всички възможни повреди са там по време на компилиране.
Сега имаме нашето обаждане до външната услуга, да предположим, че трябва да управляваме само Резервации със статус „Потвърдено“ и с някаква стойност за агенцията. Също така искаме да моделираме нашите валидации, така че да е ясно като вода как нашата услуга може да се провали.
Колко пъти сте попълвали формуляр, след което сте го изпращали. Изскача грешка, че потребителското име вече е заето, променяте го и след това го изпращате отново. Появява се друга грешка, че адресът ви няма очаквания формат. Приемате името на Господа напразно и се чудите защо всички грешки при проверката се събират наведнъж... Ето го валидиран тип данни.
Ние изброяваме нашите грешки, както направихме в нашето хранилище, за да обхванем всички възможни пътища, както правехме преди.
„Тук“ е останалата част от примера, обхващащ REST услуга от край до край, доста близка до продуктивно приложение. Можете да го стартирате и да играете с него. Има примери за всеки „провал“, който тази статия обхваща.
Моделирането на нещастния път е стъпка напред за изграждане на стабилни, устойчиви и лесни за наблюдение приложения. Тестовете са лесни за писане и много по-лесно за покриване на вашия код. Без повече изненади в 3 сутринта :)
Приятно кодиране!
