Върнете null или хвърлете изключение още веднъж

Вече потърсих отговора на този въпрос и намерих следните предложения:

  1. Ако винаги очаквате да намерите стойност, хвърлете изключението, ако липсва. Изключението би означавало, че има проблем. Ако стойността може да липсва или да присъства и двете са валидни за логиката на приложението, тогава се връща нула.
  2. Хвърлете изключение само ако наистина е грешка. Ако се очаква обектът да не съществува, върнете нулата.

Но как трябва да ги тълкувам в моя (толкова случаен) случай: контролерът на моето уеб приложение получава заявка за показване на подробности за потребител с определен идентификатор. Контролерът иска от сервизния слой да получи потребителя и след това услугата връща обекта, ако бъде намерен. Ако не, се издава пренасочване към местоположението по подразбиране.

Какво трябва да направя, когато някой предаде невалиден потребителски идентификатор в URL адреса на заявката? Трябва ли да го считам за „очаквано поведение“ и да върна null на контролера, или може би трябва да го нарека „проблем или неочаквано поведение“ и по този начин да хвърля изключение в метода на услугата и да се хвана вътре в контролера?

Технически в крайна сметка не е голяма разлика, но бих искал да го направя по правилния начин, като следвам стандартните правила. Благодаря предварително за всякакви предложения.

РЕДАКТИРАНЕ: Предполагам, че URL адресите, генерирани от приложението, са валидни и съществуващи - когато щракне от потребител, трябва да бъде намерен потребителят с определен идентификатор. Искам да знам как да се справя със ситуация, когато потребител се опита да получи достъп до URL адрес с грешен (несъществуващ) потребителски идентификатор, като ръчно въведе URL адреса в адресната лента на браузъра.


java exception null convention
person user1293910asd    schedule 23.01.2011    source източник

Отговори (3)


arrow_upward
4
arrow_downward

Ако ви разбирам правилно, заявката, съдържаща потребителското име, идва от клиент (извън вашия контрол). Прилагайки практическите правила, които цитирахте: невалидното потребителско въвеждане е напълно очакван случай, който не изисква изключение, по-скоро се справя с нулевата стойност елегантно, като връща подходящо съобщение за грешка на клиента.

(OTOH, ако потребителският идентификатор в заявката беше автоматично генериран от друго приложение / идващ от DB и т.н., невалиден потребителски идентификатор би бил неочакван, следователно изключение би било подходящо.)

person Péter Török    schedule 23.01.2011

arrow_upward
0
arrow_downward

Моето лично предложение би било да регистрирате подробностите за грешката (IP адрес, невалиден потребителски идентификатор) и да пренасочите потребителя към страница за грешка, която казва, че е възникнала грешка и администраторите са били уведомени. Щракнете върху връзката so-n-so, за да се върнете към началната си страница и т.н.

Важното е, че независимо дали хвърляте изключение или връщате null, просто се уверете, че най-външният филтър или манипулатор "регистрира" подробностите, преди отговорът да бъде върнат на потребителя.

person Sanjay T. Sharma    schedule 23.01.2011

arrow_upward
0
arrow_downward 

What should I do when someone passes invalid user id inside the request URL?

Имате два избора: покажете страницата „по подразбиране“, която споменахте, или върнете „Не е намерено“ / 404.

Относно null, зависи. Ако смятате, че null е неприемлив за препратка, тогава го анотирайте с @NotNull и анотацията ще се погрижи да направи правилното нещо при получаване на null препратка: т.е. хвърляне на (непроверено) изключение (разбира се, трябва да работите с невероятната анотация @NotNull, за да работи това).

Какво ще направите по-високо по веригата зависи от вас: за мен връщането на 404 на някой, който се опитва да фалшифицира потребителски идентификатори, звучи много близо до оптималното.

person SyntaxT3rr0r    schedule 23.01.2011