Вот именно поэтому метод называется SendMessage. Задача этого метода — отправить сообщение.
значит таки задача в отправке сообщения, а не в выбросе исключения, если письмо не отправлено? То есть выброс эксепшина не является частью задачи! Исключение — это не часть плана, это вне плана.
Потому же, почему в методе не пишут CheckArguments, CompleteSuccessfully и так далее — есть соглашения об обязанностях, зафиксированные в гайдлайнах (и я их цитировал).
потому что это не является задачей метода. Его задача не «удачно завершится» и не «проверить аргументы». Его задача — выполнить то, что написано в названии. Если наименование кода не охватывает его назначение в полной мере — это плохо названный код.
P.S. Ответьте пожалуйста на вопрос, это Вы дизлайкаете мои ответы Вам или не Вы? )
Почему? Какое формальное общепринятое правило об этом говорит?
если Вы под «возможно» имеете ввиду «возможно что угодно», то да. Но в таком значении оно теряет смысл, потому что не соответствует критерию Поппера. Если же считать под «возможно» то, что должно иногда происходить, то оно не может называться «goes wrong», потому что неправильным было бы наоборот, если бы никогда не происходило то, что должно иногда происходить :) А вот иногда происходящее то, что и должно иногда происходить — это не wrong, а right ))
Задача кода — уведомить вызывающего, что запрошенная им операция не была выполнена. Эта задача прекрасно выполняется брошенным эксепшном.
То есть код звался WarnAboutFailedOperation? Если нет, то почему название Вашего метода не соответствует решаемой задаче?
Название метода позволяет и ту, и другую трактовку. Поэтому можно сделать и так, и так.
там не написано GetLastErrorOrNoOne. Никаких других трактовок у GetLastError нет. А то, что Вы предлагаете метод называть как переменную (начиная с существительного, а не глагола) — Вы просто нарушаете рекомендации по именованию методов. Если Вы предложили заменить метод на свойство объекта (я просто не знаком с синтаксисом), то это уклонение от вопроса.
А на ваш вопрос нет однозначного ответа. Я бы бросал эксепшн, потому что это исключает ситуацию, когда мы взяли «типа последний id» и передали его дальше как валидный.
И Вы бросали бы эксепшин в методе GetSubstringOffset (название выдумано, не знаю как в C# для этого функция зовётся), если подстрока в строке не найдена? Или Вы поступили бы так, как принято обычно (например в паскале и многих других языках), и возвращали бы -1? Если тут Вы не бросали бы исключение, то поясните чем эта ситуация отличается от GetLastId.
P.S. Это Вы дизлайкаете мои ответы? Если да — могу перестать отвечать, если они Вас так раздражают )
убираем «ошибочное» и оставляем «неверное/неправильное» (два других перевода слова wrong).
Но при этом мы можем предполагать, что такой результат возможен, и дать пользователю возможность повторить операцию, или выбрать другое место, или еще что-нибудь.
если для кода, который пытался сохранить и не смог, эта ситуация описывается как «something goes wrong», то в контексте этого кода утверждение «Но при этом мы можем предполагать, что такой результат возможен» является неверным. То есть в этом контексте ситуация произойти не должна была. Но парочкой уровней выше вполне может быть код, задача которого — если файл не сохранился, то попробовать повторить операцию ещё 2 раза и сообщить результат. И этот код уже эксепшинов бросать не будет (и зваться будет не saveFile, а trySaveFile с параметром numberTries), потому что он уже предполагает, что файл может не сохраниться :)
название метода было PerformTheContract? Если нет, то почему Вы в методе решаете эту задачу. Какова была задача метода, и как эту задачу можно решить бросив исключение? Приведите хоть один пример (ну кроме того комедийного, который я сам выше привёл)
Зависит от его контракта.
как так, если Вы ранее сами цитировали источник, где сразу после процитированной Вами фразы идёт правило взятое в рамочку
An exception is when a member fails to complete the task it is supposed to
perform as indicated by its name.
и кажется Вы эту фразу даже где-то выше сами также цитировали (но это не точно). Так всё же этот источник говорит правду или врёт? Следуя его рекомендациям нужно ли выбросить эксепшин из метода getLastError, если ошибок ещё не было и возвращать нечего?
Операция Enumerable.Last, например, бросает ошибку, если в множестве нет элементов.
это не отвечает на мой вопрос. Enumerable.Last не может вернуть пустой объект нужного типа (не у всех типов есть понятие нуля), в то время как getLastId может при наличии определения нуля (то есть при однозначности значения, которое идёт до первого). Дайте ответ на вопрос, пожалуйста, не хочу додумывать его за Вас и порождать лишнюю причину для несогласия (когда Вы потом скажете «это не я сказал, а Вы придумали»).
само название не слышал, а идея очевидна. Но тут речь не про то «откуда он будет вызван», а про специфику кода. Это метод приватный, и этим он принципиально отличается от публичного. В данном подходе приватный метод не должен вообще бросать эксепшин в связи с ошибкой входных данных, потому что проверка входных данных находится не в его зоне ответственности. Таким образом мой вопрос касается только публичных методов. Итак val = null на входе в публичный метод является правильным значением или неправильным? Ну например, если val — это строка, для которой нужно посчитать какой-то хэш, то val = null является неверным значением, потому что Вы собираетесь считать только хэш строки. Так вот в Вашем случае val = null является верным значением на входе?
Да, конечно.
исходя из сказанного Вами выше — нет :) Не знаю зачем Вы говорите «да», если на самом деле Вы пишите разное поведение для методов основываясь на их собственных особенностях. И просто договорились, что приватные методы данные не проверяют (не ответственны за их верность).
Но если я буду вставлять проверку на такие «ненормальные» значения в каждом методе, код распухнет до невозможности.
так и не надо в каждом методе. Определите того, кто за это ответственен и проверяйте там. Положите слой валидаторов между внешними источниками данных и кодом, который с ними работает. Если накатывает паранойя, то можно ещё в несколько самых критичных мест добавить, где вот ну совсем нельзя, чтобы что-то пошло не по плану. Но зачастую это излишне, и при наличии слоя валидаторов сам код обычно проверяет только окружение (ну или точнее реагирует, если неправильное окружение как-то мешает правильно выполнить задачу).
Too much defensive programming creates problems of its own. If you check data passed as parameters in every conceivable way in every conceivable place, your program will be fat and slow. What's worse, the additional code needed for defensive programming adds complexity to the software.
да, об этом и говорю. Входящие извне данные проверяются валидаторами («извне» тут определяется программистом, он по своему усмотрению определяет области безопасных данных), а сам код уже реагирует только на ошибки окружения, которые возникают/обнаруживаются в ходе выполнения задачи.
Она возникла потому, что где-то в вызывающем коде кто-то передал null.
))) я догадался. Вопрос был о сути причины, а не об очевидной констатации факта в следствии которого в метод попадают неверные данные. Это как на вопрос «почему солнце светится» ответить «потому что оно излучает свет» — я бы сам не догадался )))
Я помогаю себе найти место, где случилась ошибка в проде.
а чем Вас не устраивает системное исключение? у него нет стека вызовов? Почему Ваш код высокого уровня ловит ошибки произошедшие на низком уровне, и спровоцированные более высоким уровнем? То есть к этой ошибке отношение имеют все, кроме того кода, в котором Вы эту ошибку решаете ловить :)
Не обязательно. Еще могут иметь в виду общебытовое значение слова «error».
В технической литературе скорее всего имеют ввиду техническое значение термина. Я не говорю, что точно имеют ввиду, но если нет возможности это определить, то имеет смысл считать, что термин используется в соответствии со значением в соответствующем словаре.
Никакого «неверного пути». Его там нет. Просто «что-то идет не так»
хорошо, если убираем моё уточнение, то тогда следует лучше подобрать слова: «происходит что-то ошибочное/неверное».
Кто «мы»?
наш код. То есть мы в лице кода, который написали, чтобы он делал что-то вместо нас.
Пользователь?
нет, если только мы не автоматизируем работу пользователя. Тут речь про того, чьи действия заменяются кодом.
А где вы взяли «wrong way»? В вашей цитате его нет.
да, Вы правы, перевёл свою же фразу обратно, похоже. Ладно, эта часть для меня не существенна. Меня просто устроит замена «происходит не так» на «происходит что-то ошибочное/неверное», что является достаточно точный выражением смысла текста.
Я не планирую, что его где-то кто-то как-то обработает, с чего вы это взяли?
Вы сами сказали, что бросить эксепшин — это часть плана. Вы считаете, что когда бросили эксепшин, то решили поставленную задачу? Если нет, но при этом утверждаете, что сам эксепшин является часть плана, значит просто обязаны что-то планировать дальше для решения задачи. Или у Вас в планах есть вариант «не решать задачу»? )
Да. И у вас нет никакого объективного способа доказать мне, что я неправ.
это был Ваш аргумент, а не мой. Странно говорить, что если я не доказал, что Ваш аргумент неверен, то он верен. )
When an action member cannot complete its task, the member should throw an exception.
должен ли метод getLastError бросить исключение, если до его вызова не произошло ни одной ошибки? По сути я ведь не могу получить последнюю ошибку, если ошибок не было, а значит этот метод не выполняет заявленную в названии задачу. Должно быть исключение? Или он может вернуть статус NO_ERRORS?
А getLastId должен бросить исключение, если нет ни одной записи (ни одного id ещё нет), или он может вернуть 0, чтобы код мог прибавить 1 и добавить первую запись?
то есть инкапсуляции 0? Когда Вы пишите код, то задумываетесь о том, откуда его будут вызывать и учитываете особенности кода, к которому Ваш не имеет никакого отношения? Сам Ваш код что предполагает? Для него val = null — это нормальное значение, или это то, что в него попадать не должно (по смыслу переменной там должен быть не null)? Если это нормальное значение — обрабатывайте его, код на это рассчитан. Если не нормальное — бросайте исключение, Вам обещано другое (Вы свой код писали не планируя такие данные получать)
Мне — не нравится
Вопрос не в «нравится или нет», а в том почему ошибка возникла. Если Вы работаете со строкой, то проверьте её содержание, если к нему есть какие-то требования. Но не надо проверять то, за что не ответственны. Например если типы данных контролируются фреймворком — оставьте это ему. Если же это задача Вашего уровня кода — конечно ловите ошибки сами и бросайте эксепшины. Ну это как с менеджментом, как я уже говорил. Ген.директор может стоять у программиста над головой и указывать на допущенные опечатки и ошибки в коде, а может сидеть и заниматься тем, чем ему положено — управлением компании. И вот когда он занимается управлением компании, то она с большей вероятностью процветает, чем когда он стоит над головой у программиста и «помогает». Так и Ваш код, который помогает фреймворку с его задачей вместо выполнения собственных, делает слегка не то, что нужно.
Я то что могу сделать? Я Вам предложил перейти на конкретную терминологию, Вы же сказали, что не хотите, Вам она не нравится. И продолжили называть ошибкой то, что я называю статусом выполнения операции. Проблема в том, что если я начну это называть ошибкой как и Вы делаете, что я не смогу выразить то понятие, которое я сейчас ошибкой зову в беседе. Просто другого подходящего слова для него нет. Ну и вторая проблема в том, что часто в источниках ошибка понимается в том значении, которое я озвучил, а потому считая, что везде под ошибкой понимается отрицательный статус выполнения операции, мы будем неверно интерпретировать написанный текст.
вот определение ошибки в кэмбридском словаре в разделе IT
a situation in which something goes wrong in a computer program, or a message that this has happened:
То есть когда в книгах пишут error, то вероятнее всего имеют ввиду именно это. «ситуация, в которой что-то идёт не так (по неверному пути) в компьютерной программе или сообщение об этом.» Когда мы получаем тот результат, который предполагали получить, то это не называет «не так» или «по неверному пути». То есть wrong way — это то, что произойти не должно. А это именно тот случай, в котором и надо бросать эксепшин по моему мнению. Вы же желаете понимать под этим словом другое — некоторый вполне ожидаемый результат, когда всё идёт по плану, и код получил отрицательный ответ, который в принципе и планировал иногда получать :) Это никакое не wrong way ))
Но почему? Я не использую исключение, чтобы перейти куда-то.
потому что если Вы бросаете исключение «по плану», то Вы это делаете для того, чтобы остановить выполнение кода, перескочить на несколько уровней выше и там что-то сделать. Это и есть обычный goto. А вот если Вы кидаете исключение потому, что что-то пошло не по плану, то тогда Вы говорите «я по плану работу провести не могу, потому разбирайтесь там выше почему вы мне не подготовили среду для работу». Каждый раз, когда Вы будете бросать эксепшин по плану, именно планируя, что код выше его как-то конкретным образом обработает — Вы будете писать неправильный код. Момент генерации исключения — это место, где у Вас больше нет никакого плана и Вы понятия не имеете что будет дальше.
Основная проблема в том, что это вы считаете, что я делаю неправильно; в то время как я делаю в соответствии с гайдлайнами платформы, для которой я пишу. Странно, правда?
Отвечу как Вы мне ранее: «это Ваше субъективное мнение, что Вы пишите в соответствии с гайдлайнами».
В Ваш блок должна переменная val передаваться как null? То есть это вариант правильных входных данных и окружения, которые предусмотрены в коде? Или это тот вариант данных, при котором код будет вести себя непредсказуемым или гарантированно неверным образом? Если это правильные входные данные — эксепшину не место. Если неправильные — место. Если Ваш уровень кода эту переменную не контролирует, а просто делегирует работу с ней на уровень ниже — эксепшин не нужен, так как это ответственность более низкоуровневого кода. не нужно заниматься микроменеджментом и пытаться отслеживать каждую мелочь, нужно отслеживать всё, что важно для Вашего масштаба выполнения задачи. И тут дело совсем не в том бросит ли более низкоуровневый код свой эксепшин или не бросит, тут важно то насколько Вы за это ответственны. Например высокоуровневый код не должен заботиться о правильности адресов данных в памяти, он должен заботиться о самих данных. Потому если на вашем уровне кода Вы работаете с изображением в памяти, то надо бросить эксепшин если Вам прислали неправильные координаты пикселя, но не надо пытаться отслеживать ситуацию выхода за пределы выделенной под картинку памяти — это забора другого кода, который обслуживает работу с памятью.
А теперь давайте сопоставим это с вашим же высказыванием:
я уже говорил как так получается. Слово «ошибка» понимается в двух разных значениях. В одном случае в том значении, с которым Вы не согласны, а в другом — отрицательный статус выполнения операции. В первом случае только эксепшины, во втором случае — возврат статуса. Но так как второе значение более широкое, чем первое и по сути полностью в себе первое умещает, то тут важно понимать, что многие ситуации подпадают под оба определения, и в этом случае надо идти по первому пути — бросать эксепшин.
если Вы бросаете исключение по плану, то это не исключение, а часть плана. Это значит, что Вы используете исключение как замену инструкции goto и просто создаёте запутанный и некачественный код (как тот человек, который результат валидации бросает эксепшинами, чтобы не передавать результат по цепочке наверх… вот он по плану эксепшин и бросает, только код от этого лучше не становится).
Мы всё ещё продолжаем странную беседу, когда я говорю «вот так правильно, это делает код лучше, потому что...», а Вы мне зачем-то отвечаете «а что если я делаю неправильно? как Вы это объясните?» — да никак :) ну точнее только так, что Вы это делаете неправильно, и результат будет хуже (менее читабельный, более сложный в сопровождении).
Если Вы предусмотрели ситуацию в коде и можете её обработать — обрабатывайте. Если не можете — бросайте эксепшин. Но бросит эксепшин — это не обработать. Это как называть себя победителем в состязании, в котором не участвовал ))
Т.е. мы планировали, что система, вместо того, чтобы не глядя открыть несуществующий сокет, и упасть с чем-нибудь непонятным (или, хуже того, продолжить работу), бросит нам понятный эксепшн «такого сокета нет»?
нет, мы планировали, что она откроет существующий сокет. Но если что-то пойдёт не по плану, то она выкинет эксепшин. Если Вы планировали проверить работу сокета, если не работает — бросить эксепшин, а если работает — отправить данные, то должны были назвать функцию не sendData, а throwExceptionOnUnavailablSocketOrSendDataOtherwise. Так что говоря, что бросить эксепшин являлось частью плана — Вы просто лукавите, потому что об обратном даже название функции говорит.
Ну и да, места для кодов ошибок все равно нет.
в том значении слова «ошибка», которое я приводил — да, места кодам ошибок нет. В значении «код предназначен для запроса документа по id, но при запросе документ с таким id был не найден, а значит код не выполнил предназначение и это ошибка» — в этом понимании ошибки код ошибки вполне может быть возвращён, потому что на самом деле функция выполнила своё предназначение и документ запросила, а то, что его там не было — не её вина. Она может предусматривать возвращение пустого объекта и передачу статуса произошедшей ошибки кому-то, и это будет правильно.
Как объективнно отличить ошибки, при которых надо бросать эксепшн, от ошибок, при которых надо возвращать «код ошибки»?
По всем ошибкам надо бросать исключения, если под словом «ошибка» понимать то, что я озвучил в соседнем сообщении — поведение системы, которое не прогнозировалось при её создании. Если мы планировали (рассчитывали на то), что при вызове метода ему может быть передан идентификатор несуществующего сокета, то не нужно бросать эксепшины с криками «нет такого сокета», а нужно обработать ситуацию в соответствии с планом. Если же мы такого не планировали и методу должен передаваться только ид существующего сокета — тогда определённо эксепшин, если сокета нет
Как это далеко ушло от оригинального «любой код должен вызываться по контракту, и если обнаруживается, что контракт был нарушен [...], то код должен бросить исключение, но ни в каких других случаях исключения не уместны.»
не понял. в чём далеко? )) Контракт был нарушен, потому что по контракту должно было быть обеспечено некоторое окружение, в котором код может выполнить свою задачу. Ему окружение не предоставили — он задачу не выполнил. Это ошибка вызова. То, что Вы себе придумали противоречие там, где его нет — это строго Ваше решение.
Так что это РОВНО ТО о чём я и говорил изначально.
Смотрите, вы уже согласились, что если ошибка, то нужно исключение.
я никогда ничего другого и не говорил. Ошибка — это то, что не должно происходить.
В этом случае, коды ошибок не нужны никогда (кроме как внутри исключений).
коды ошибок не нужны. Давайте внесём такое определение «ошибка» — это поведение системы отличное от прогнозируемого при её создании.
То есть если при создании программы мы рассчитывали, что программа будет всегда отдавать по http статус 200, а она отдала 404 — это ошибка. Если мы прогнозировали, что она по http будет отдавать 200, 3xx и 404 — то это всё статусы, которые мы будем передавать выше просто как результат выполнения операции. Но при этом статусы 400 и 5xx мы снова же будем считать ошибками и кидать исключения, если при создании программы мы рассчитывали, что такие статусы возникать не будут.
Тут надо понимать, что слово «ошибка» может иметь разные значения, и иногда люди используют его в отношении отрицательных статусов (ну то есть они ожидают в ответ статус http 404, но при этом именуют его ERR_NOT_FOUND просто потому, что «это же не статус успешного выполнения операции, а значит явно ошибка»)
Ну вот видите. Нет объективного способа определить, кто из нас прав.
Почему нет? Убираем из кода функцию валидации и смотрим что изменилось. Вот то, что изменилось, то и было назначением функции (то она и делала). Если убрать функцию валидации, то мы начнём получать невалидные данные и падать ошибками :) В отношении валидных данных ничего не изменится.
Мне все равно, что думает хром.
Вот Вы снова игнорируете факт, который противоречит Вашим убеждениям. Вы говорите «это не ошибка», я Вам показываю достаточно сильный продукт, где это является ошибкой, а Вы снова говорите, что не ошибка )
Статус 404 возвращает хост, но он не существует. Так что же будет?
Тут зависит от того, должен ли он был существовать. На уровне кода, который выполняет непосредственно запрос — это ошибка (нужно бросать исключение). На более высоких уровнях это может переставать быть ошибкой, например на уровне, где код знает, что адреса вбиваются человеком, это может уже не считаться ошибкой. Но на уровне самого http клиента да, это ошибка.
В таком случае под «не должно происходить» разработчик контракта может написать что угодно.
Не что угодно. Если в ТЗ написано «файл периодически может быть недоступен и это надо предусмотреть», то это значит, что на каком-то уровне программы (компонента) это точно не будет считаться ошибкой. Если же подобное не сказано — считать ошибкой на всех уровнях программы.
Если сказано «данные будут направляться другой частью системы по АПИ, и потому гарантированно будут верны», то это причина считать ошибкой любые невалидные данные и бросать исключение, а наверху ловить его и отдавать ответ «направлены неверные данные, ошибка 153». И тут было бы странно передавать статусы по цепочке вверх, потому что такое поведение было бы усложнением логики на пустом месте. Вы сейчас говорите что-то вроде «но программист может принимать любые решения, кто ему запретит?» )) с этим я согласен, может… но только одни решения лучше других. Программист может вообще принять волевое решение не использовать исключения, но код от этого лучше не станет. Он может принять решение, что при генерации случайного числа он будет не просто генерировать число, а он будет генерировать 1000 чисел, потом генерировать число от 1 до 1000, а потом брать число с соответствующим номером. Опять же да, может, но код лучше от этого точно не станет )) Также он может от балды принимать решение о том, что должно происходить, а что не должно, не учитывая назначение кода и условия описанные в задаче, но код от этого тоже станет только хуже :) Да, местами у программиста и правда есть варианты считать ли что-то недопустимым или не считать, и в этом случае пускай решает, но зачастую такое решение уже предопределено задачей, которая ставится перед написанным кодом.
С точки зрения кода, бросающего эксепшн (это важно), это то, что обязательно должно быть сделано.
с этим вполне согласен. Предлагаю не спорить на тему того нужен ли эксепшин, если код не может выполнить то, ради чего существует, потому что в этом месте я ничего не оспариваю. Ну то есть создавая код, мы рассчитываем на то, что он будет работать, а значит когда он не работает, это то, что «не должно происходить».
Что значит «критично»? Как это формально определить?
это то, о чём Вы говорили. Есть случаи, когда код может выполнить поставленную перед ним задачу, а есть тогда, когда не может. Если может — не критично. Если не может — критично.
Джеффри Рихтер (это он, а не «они») такого не говорит.
таки говорит. То есть он ссылается на то, что хоть это происходит часто, но тут надо исключение. но на самом деле это то, что не должно происходить (то есть если оно происходит часто — это ошибка в коде)
вам непонятна?
понятна. Я не понимаю связи цитаты с обсуждаемым. Ну ок, да, если результат работы метода не соответствует его названию, то это ошибка и тут нужно исключение. Ну как бы очевидно.Но как это доказывает, что исключения нужны не только тогда, когда происходит что-то, что не должно? Вы считаете, что метод должен иногда делать то, что не соответствует его названию или не делать то, что в названии заявлено?
Как рекомендация. Я и говорю: вы трактуете текст. Это субъективно.
Нет, это указание назначения. Я не трактую текст, а разбираю его исходя из законов логики, то есть максимально объективно.
Нет, не значит.
Нет. Значит! :)
Нет, она предназначена для того, чтобы пропустить дальше валидные данные.
Нет, она предназначена для того, чтобы не пропустить невалидные
Неверно. Словарь выступает кэшом (в конкретном сценарии), и вы наблюдаете cache miss. Это не ошибка.
а вот гугл хром считает это ошибкой, называется ERR_CACHE_MISS
Не, не предказуемо. Что будет, если там несуществующий хост?
предсказуемо — вернётся статус 404, как при любом URI ведущем в пустоту
Мы заведомо знаем, что достаточно сложная система не безошибочна и не безотказна.
И это значит, что ошибка может произойти, но не значит, что иногда происходящие ошибки и отказы — это нормально
Статус чего? Если выполнения операции, то да. А если операции, то нет.
чем статус операции отличается от статуса выполнения операции?
Нет, не ведет.
ведёт
Там, где мы не можем выполнить необходимую операцию.
Правильно ли я понял, что речь о чём-то, что обязательно должно быть сделано (альтернатив нет), но при этом сделано быть не может?
Но это происходит не просто «иногда», а достаточно часто (просто это укладывается в наш 99% SLO).
оу… так «не должно происходить» никак не связано с частотой происходящего. Это лишь значит, что сервер ДОЛЖЕН успеть ответить за это время и ситуация, когда он ответить не успел возникать НЕ ДОЛЖНА. При этом он может хоть в 100% случаев не отвечать, это не мешает нам бросать там исключение. При этом с программой может работать мега ответственный и внимательный человек, который допускает одну опечатку в год (то есть ошибка происходит один раз на сотни тысяч вызовов), но это не мешает нам обрабатывать ситуацию с опечатками штатно, потому что опечатки — это не то, что НЕ ДОЛЖНО происходить, а то, что вполне может быть (если по ТЗ не заявлено обратное, конечно). То есть дело не в частоте, а в «должно» / «не должно». Дело в обещанных коду условиях и в их отличии от реально предоставленных. Если отличие критично — исключение. Если не критично — всё ок, просто статус ответа.
P.S. Ответьте пожалуйста на вопрос, это Вы дизлайкаете мои ответы Вам или не Вы? )
там не написано GetLastErrorOrNoOne. Никаких других трактовок у GetLastError нет. А то, что Вы предлагаете метод называть как переменную (начиная с существительного, а не глагола) — Вы просто нарушаете рекомендации по именованию методов. Если Вы предложили заменить метод на свойство объекта (я просто не знаком с синтаксисом), то это уклонение от вопроса.
И Вы бросали бы эксепшин в методе GetSubstringOffset (название выдумано, не знаю как в C# для этого функция зовётся), если подстрока в строке не найдена? Или Вы поступили бы так, как принято обычно (например в паскале и многих других языках), и возвращали бы -1? Если тут Вы не бросали бы исключение, то поясните чем эта ситуация отличается от GetLastId.
P.S. Это Вы дизлайкаете мои ответы? Если да — могу перестать отвечать, если они Вас так раздражают )
если для кода, который пытался сохранить и не смог, эта ситуация описывается как «something goes wrong», то в контексте этого кода утверждение «Но при этом мы можем предполагать, что такой результат возможен» является неверным. То есть в этом контексте ситуация произойти не должна была. Но парочкой уровней выше вполне может быть код, задача которого — если файл не сохранился, то попробовать повторить операцию ещё 2 раза и сообщить результат. И этот код уже эксепшинов бросать не будет (и зваться будет не saveFile, а trySaveFile с параметром numberTries), потому что он уже предполагает, что файл может не сохраниться :)
как так, если Вы ранее сами цитировали источник, где сразу после процитированной Вами фразы идёт правило взятое в рамочку и кажется Вы эту фразу даже где-то выше сами также цитировали (но это не точно). Так всё же этот источник говорит правду или врёт? Следуя его рекомендациям нужно ли выбросить эксепшин из метода getLastError, если ошибок ещё не было и возвращать нечего?
это не отвечает на мой вопрос. Enumerable.Last не может вернуть пустой объект нужного типа (не у всех типов есть понятие нуля), в то время как getLastId может при наличии определения нуля (то есть при однозначности значения, которое идёт до первого). Дайте ответ на вопрос, пожалуйста, не хочу додумывать его за Вас и порождать лишнюю причину для несогласия (когда Вы потом скажете «это не я сказал, а Вы придумали»).
исходя из сказанного Вами выше — нет :) Не знаю зачем Вы говорите «да», если на самом деле Вы пишите разное поведение для методов основываясь на их собственных особенностях. И просто договорились, что приватные методы данные не проверяют (не ответственны за их верность).
так и не надо в каждом методе. Определите того, кто за это ответственен и проверяйте там. Положите слой валидаторов между внешними источниками данных и кодом, который с ними работает. Если накатывает паранойя, то можно ещё в несколько самых критичных мест добавить, где вот ну совсем нельзя, чтобы что-то пошло не по плану. Но зачастую это излишне, и при наличии слоя валидаторов сам код обычно проверяет только окружение (ну или точнее реагирует, если неправильное окружение как-то мешает правильно выполнить задачу).
да, об этом и говорю. Входящие извне данные проверяются валидаторами («извне» тут определяется программистом, он по своему усмотрению определяет области безопасных данных), а сам код уже реагирует только на ошибки окружения, которые возникают/обнаруживаются в ходе выполнения задачи.
))) я догадался. Вопрос был о сути причины, а не об очевидной констатации факта в следствии которого в метод попадают неверные данные. Это как на вопрос «почему солнце светится» ответить «потому что оно излучает свет» — я бы сам не догадался )))
а чем Вас не устраивает системное исключение? у него нет стека вызовов? Почему Ваш код высокого уровня ловит ошибки произошедшие на низком уровне, и спровоцированные более высоким уровнем? То есть к этой ошибке отношение имеют все, кроме того кода, в котором Вы эту ошибку решаете ловить :)
хорошо, если убираем моё уточнение, то тогда следует лучше подобрать слова: «происходит что-то ошибочное/неверное».
наш код. То есть мы в лице кода, который написали, чтобы он делал что-то вместо нас.
нет, если только мы не автоматизируем работу пользователя. Тут речь про того, чьи действия заменяются кодом.
да, Вы правы, перевёл свою же фразу обратно, похоже. Ладно, эта часть для меня не существенна. Меня просто устроит замена «происходит не так» на «происходит что-то ошибочное/неверное», что является достаточно точный выражением смысла текста.
это был Ваш аргумент, а не мой. Странно говорить, что если я не доказал, что Ваш аргумент неверен, то он верен. )
должен ли метод getLastError бросить исключение, если до его вызова не произошло ни одной ошибки? По сути я ведь не могу получить последнюю ошибку, если ошибок не было, а значит этот метод не выполняет заявленную в названии задачу. Должно быть исключение? Или он может вернуть статус NO_ERRORS?
А getLastId должен бросить исключение, если нет ни одной записи (ни одного id ещё нет), или он может вернуть 0, чтобы код мог прибавить 1 и добавить первую запись?
Вопрос не в «нравится или нет», а в том почему ошибка возникла. Если Вы работаете со строкой, то проверьте её содержание, если к нему есть какие-то требования. Но не надо проверять то, за что не ответственны. Например если типы данных контролируются фреймворком — оставьте это ему. Если же это задача Вашего уровня кода — конечно ловите ошибки сами и бросайте эксепшины. Ну это как с менеджментом, как я уже говорил. Ген.директор может стоять у программиста над головой и указывать на допущенные опечатки и ошибки в коде, а может сидеть и заниматься тем, чем ему положено — управлением компании. И вот когда он занимается управлением компании, то она с большей вероятностью процветает, чем когда он стоит над головой у программиста и «помогает». Так и Ваш код, который помогает фреймворку с его задачей вместо выполнения собственных, делает слегка не то, что нужно.
вот определение ошибки в кэмбридском словаре в разделе IT
То есть когда в книгах пишут error, то вероятнее всего имеют ввиду именно это. «ситуация, в которой что-то идёт не так (по неверному пути) в компьютерной программе или сообщение об этом.» Когда мы получаем тот результат, который предполагали получить, то это не называет «не так» или «по неверному пути». То есть wrong way — это то, что произойти не должно. А это именно тот случай, в котором и надо бросать эксепшин по моему мнению. Вы же желаете понимать под этим словом другое — некоторый вполне ожидаемый результат, когда всё идёт по плану, и код получил отрицательный ответ, который в принципе и планировал иногда получать :) Это никакое не wrong way ))
Отвечу как Вы мне ранее: «это Ваше субъективное мнение, что Вы пишите в соответствии с гайдлайнами».
докажите ссылкой, пожалуйста
Мы всё ещё продолжаем странную беседу, когда я говорю «вот так правильно, это делает код лучше, потому что...», а Вы мне зачем-то отвечаете «а что если я делаю неправильно? как Вы это объясните?» — да никак :) ну точнее только так, что Вы это делаете неправильно, и результат будет хуже (менее читабельный, более сложный в сопровождении).
Если Вы предусмотрели ситуацию в коде и можете её обработать — обрабатывайте. Если не можете — бросайте эксепшин. Но бросит эксепшин — это не обработать. Это как называть себя победителем в состязании, в котором не участвовал ))
нет, мы планировали, что она откроет существующий сокет. Но если что-то пойдёт не по плану, то она выкинет эксепшин. Если Вы планировали проверить работу сокета, если не работает — бросить эксепшин, а если работает — отправить данные, то должны были назвать функцию не sendData, а throwExceptionOnUnavailablSocketOrSendDataOtherwise. Так что говоря, что бросить эксепшин являлось частью плана — Вы просто лукавите, потому что об обратном даже название функции говорит.
в том значении слова «ошибка», которое я приводил — да, места кодам ошибок нет. В значении «код предназначен для запроса документа по id, но при запросе документ с таким id был не найден, а значит код не выполнил предназначение и это ошибка» — в этом понимании ошибки код ошибки вполне может быть возвращён, потому что на самом деле функция выполнила своё предназначение и документ запросила, а то, что его там не было — не её вина. Она может предусматривать возвращение пустого объекта и передачу статуса произошедшей ошибки кому-то, и это будет правильно.
Так что это РОВНО ТО о чём я и говорил изначально.
я никогда ничего другого и не говорил. Ошибка — это то, что не должно происходить.
коды ошибок не нужны. Давайте внесём такое определение «ошибка» — это поведение системы отличное от прогнозируемого при её создании.
То есть если при создании программы мы рассчитывали, что программа будет всегда отдавать по http статус 200, а она отдала 404 — это ошибка. Если мы прогнозировали, что она по http будет отдавать 200, 3xx и 404 — то это всё статусы, которые мы будем передавать выше просто как результат выполнения операции. Но при этом статусы 400 и 5xx мы снова же будем считать ошибками и кидать исключения, если при создании программы мы рассчитывали, что такие статусы возникать не будут.
Тут надо понимать, что слово «ошибка» может иметь разные значения, и иногда люди используют его в отношении отрицательных статусов (ну то есть они ожидают в ответ статус http 404, но при этом именуют его ERR_NOT_FOUND просто потому, что «это же не статус успешного выполнения операции, а значит явно ошибка»)
Вот Вы снова игнорируете факт, который противоречит Вашим убеждениям. Вы говорите «это не ошибка», я Вам показываю достаточно сильный продукт, где это является ошибкой, а Вы снова говорите, что не ошибка )
Тут зависит от того, должен ли он был существовать. На уровне кода, который выполняет непосредственно запрос — это ошибка (нужно бросать исключение). На более высоких уровнях это может переставать быть ошибкой, например на уровне, где код знает, что адреса вбиваются человеком, это может уже не считаться ошибкой. Но на уровне самого http клиента да, это ошибка.
Не что угодно. Если в ТЗ написано «файл периодически может быть недоступен и это надо предусмотреть», то это значит, что на каком-то уровне программы (компонента) это точно не будет считаться ошибкой. Если же подобное не сказано — считать ошибкой на всех уровнях программы.
Если сказано «данные будут направляться другой частью системы по АПИ, и потому гарантированно будут верны», то это причина считать ошибкой любые невалидные данные и бросать исключение, а наверху ловить его и отдавать ответ «направлены неверные данные, ошибка 153». И тут было бы странно передавать статусы по цепочке вверх, потому что такое поведение было бы усложнением логики на пустом месте. Вы сейчас говорите что-то вроде «но программист может принимать любые решения, кто ему запретит?» )) с этим я согласен, может… но только одни решения лучше других. Программист может вообще принять волевое решение не использовать исключения, но код от этого лучше не станет. Он может принять решение, что при генерации случайного числа он будет не просто генерировать число, а он будет генерировать 1000 чисел, потом генерировать число от 1 до 1000, а потом брать число с соответствующим номером. Опять же да, может, но код лучше от этого точно не станет )) Также он может от балды принимать решение о том, что должно происходить, а что не должно, не учитывая назначение кода и условия описанные в задаче, но код от этого тоже станет только хуже :) Да, местами у программиста и правда есть варианты считать ли что-то недопустимым или не считать, и в этом случае пускай решает, но зачастую такое решение уже предопределено задачей, которая ставится перед написанным кодом.
с этим вполне согласен. Предлагаю не спорить на тему того нужен ли эксепшин, если код не может выполнить то, ради чего существует, потому что в этом месте я ничего не оспариваю. Ну то есть создавая код, мы рассчитываем на то, что он будет работать, а значит когда он не работает, это то, что «не должно происходить».
это то, о чём Вы говорили. Есть случаи, когда код может выполнить поставленную перед ним задачу, а есть тогда, когда не может. Если может — не критично. Если не может — критично.
понятна. Я не понимаю связи цитаты с обсуждаемым. Ну ок, да, если результат работы метода не соответствует его названию, то это ошибка и тут нужно исключение. Ну как бы очевидно.Но как это доказывает, что исключения нужны не только тогда, когда происходит что-то, что не должно? Вы считаете, что метод должен иногда делать то, что не соответствует его названию или не делать то, что в названии заявлено?
Нет. Значит! :)
Нет, она предназначена для того, чтобы не пропустить невалидные
а вот гугл хром считает это ошибкой, называется ERR_CACHE_MISS
предсказуемо — вернётся статус 404, как при любом URI ведущем в пустоту
И это значит, что ошибка может произойти, но не значит, что иногда происходящие ошибки и отказы — это нормально
чем статус операции отличается от статуса выполнения операции?
ведёт
Правильно ли я понял, что речь о чём-то, что обязательно должно быть сделано (альтернатив нет), но при этом сделано быть не может?
оу… так «не должно происходить» никак не связано с частотой происходящего. Это лишь значит, что сервер ДОЛЖЕН успеть ответить за это время и ситуация, когда он ответить не успел возникать НЕ ДОЛЖНА. При этом он может хоть в 100% случаев не отвечать, это не мешает нам бросать там исключение. При этом с программой может работать мега ответственный и внимательный человек, который допускает одну опечатку в год (то есть ошибка происходит один раз на сотни тысяч вызовов), но это не мешает нам обрабатывать ситуацию с опечатками штатно, потому что опечатки — это не то, что НЕ ДОЛЖНО происходить, а то, что вполне может быть (если по ТЗ не заявлено обратное, конечно). То есть дело не в частоте, а в «должно» / «не должно». Дело в обещанных коду условиях и в их отличии от реально предоставленных. Если отличие критично — исключение. Если не критично — всё ок, просто статус ответа.