Как пользователю мне, за исключением некоторых мелочей, вполне удобны существующие авиапоисковики.
То что там называется «поиск» на самом деле не совсем поиск (и уж тем более не поиск ключей), а фактически выбор свойств желаемого.
То есть вот надо мне 15 января попасть из Москвы в Стамбул, я говорю сервису: когда, откуда и куда. Сервис показывает варианты. Все быстро и просто.
А концепция «первый экран приложения содержит готовые предложения, а не фильтры.» — это как раз рекламный bullshit, который не нужен пользователю. Ему не надо «на море» и «в горы». Пользователь, пришедший на авиапоисковик, уже знает куда и когда ему надо.
Поэтому первая страница должна содержать именно параметры запроса.
Время покажет.
Мне этот подход скорее напоминает checked exceptions в java.
То бишь есть обычные exceptions, а есть checked exceptions.
Есть обычные коды возвращаемых ошибок, а тут checked коды.
В обоих случаях авторы фичи преследуют благую, казалось бы, цель: сделать возврат ошибок более явным, чтобы было понятно какие ошибки откуда берутся и их было сложнее проигнорировать.
Но сейчас, годы спустя, checked exceptions считается неудавшимся дизайном. Например, в том же C# от них осознанно отказались.
Здесь очень похожая ситуация, форсирование обработки, только механизм передачи сделан не через исключение, а через возвращаемое значение.
Ну почти тоже самое. Серебряная пуля — метод который решает существующие проблемы гораздо эффективнее, чем предыдущие методы. Представляем java — новый язык, на котором мы будем писать программы в несколько раз эффективней, чем на допотопном C++. Представляем обработку ошибок в Go — мы будем обрабатывать их гораздо эффективнее чем в предыдущих языках. Метафора в общем то про это.
С долгосрочностью/краткосрочностью совсем не понятно. Что является осью времени, на которой мы измеряем эту долгосрочность? Работа программы? Жизнь программиста? Развитие IT индустрии?
Ну она так воспринимается. Что есть старый путь, через исключения, «неправильный». А есть новый, «правильный». Который вроде как благодаря легкости и простоте должен подтолкнуть программистов к правильной обработке ошибок.
А комментарии же уже после идут, отдельно. Извиняюсь, если оскорбил.
Если лишь 1 вызов из многих содержит ошибку, то конечно проблемы нет.
Однако бывают код, и это отнюдь не редкость, а вполне распространен на практике, в котором интенсивность содержания ошибок высокая. И с этим тоже надо что-то делать. Собственно я именно про такой код и задал вопрос.
В случае исключений до самой main падать не нужно. Обычно используется паттерн с большим try catch, наложенным на какую-то высокоуровневую операцию, который ловит все подряд. Ну тот же пример с web server, который генерит страницу. В процессе генерации страницы может случится всякое, ведь он же в том числе ходит за данными и во внешние источники. Но что бы ни случилось, обработка будет одна и та же: пользователю отдаем страницу 500, а техническому специалисту печатаем текст ошибки в лог.
Паттерн отлично работает, причем web сервер лишь пример, его можно применять еще много где.
Вот это действительно удобный подход, который позволяет программисту писать простой линейный код и снимает с него головную боль обработки бесчисленных fail path, которые случиться во время генерации. Соотношение код обработки ошибок/основной код сведено к минимуму.
Ну я так понял, что panic — это не основная схема, а вспомогательная. Что по задумке авторов языка panic нельзя злоупотреблять, что основным способом обработки ошибок должен быть error.
Но если оказывается, что основная схема неудобна, то есть опасность что пользователь перейдет на вспомогательную, но более удобную для него.
Например, на все нужные ему стандартные пакеты напишет врапперы, которые превратят error в panic, забьет на инновацию языка авторов и будет работать по старому, с исключениями. Можно даже сделать библиотеку error2panic, выложить в opensource и она будет пользоваться популярностью.
Да, это хорошо, что язык предоставляет возможность обойти авторскую задумку и работать по старому, но мне все-таки интересно, можно ли удобно пользоваться новым способом.
Дело в том, что этот вариант является, как мне кажется, основным разумным поведением по умолчанию. И именно так работает обработка ошибок на исключениях, люди к этому уже привыкли.
После каждого вызова писать if r.err — это не выход, это принять страдания и смириться. Но ведь тут речь идет об удобстве, о том что простой и удобный синтаксис будет подталкивать программистов к правильному написанию программ.
Я всецело согласен с тезисом, что простота и удобство синтаксиса является мощным мотиватором для программистов, но я вижу, что обработка ошибок в Go создает огромную проблему, которая перекрывает все преимущества такого подхода. И решения этой проблемы я пока не вижу. Поэтому исключения для меня пока что выглядят куда проще и удобней, чем этот механизм.
Спасибо за ссылку.
Но вообще этот вопрос настолько важен, что мне кажется в статье про «серебряную пулю для обработки ошибок» нельзя это не упомянуть. Это я, разумеется, не Вам, а автору статьи.
Что касается решения, которое изложено в ссылке, то оно не является полным решением проблемы
1. Что делать, если мне все-таки нужно поведение, когда, при возникновении ошибки в очередной строчке, мне нужно сразу же завершить выполнение фрагмента? А отложить ошибку в сторону и проверить в конце нельзя, так как остаток фрагмента кода будет работать с битыми данными, а это плохо.
2. Предлагаемый в ссылке паттерн на самом деле сводит основное рекламируемое свойство Go на нет: программист в этом паттерне волен легко проигнорировать ошибку. То есть это уже не будет иметь никаких принципиальных преимуществ над обычными кодами возврата.
Код, в котором вызывается 10 раз подряд одна и та же функция, ошибки от которой нужно обрабатывать абсолютно одинаково — то да, исключения дают более читабельный код. Нюанс в том, что такой код редко встречается, и если и встречается — то это повод для рефакторинга.
Как раз таки очень часто встречается. Представьте себе например, что вы работаете с базой. Или с сетью. И вот у вас кусок кода который в каждой строчке в эту базу или сеть лазит. И из каждой строчки потенциально может вылететь IOException.
Не имея возможности завернуть этот кусок кода в единый try catch, проверяя ошибочный результат на каждую операцию, вы просто задолбаетесь.
А код распухнет вдвое, его логику будет сложнее читать из-за этих if err != nil на каждой второй строчке.
Доступность сообщений на клиенте отдана на откуп интерфейсу. Если его сломать можно слать какие угодно сообщения кому угодно. Но везде, где это хоть сколько-нибудь опасно или должно быть ограниченно игрой есть серверные проверки. Тогда в логах сервера будут ошибки, мы их увидим и плохого игрока… кхм… накажем :)
Просто по этому абзацу может создаться ошибочное впечатление, что если взломать сетевой протокол, то можно выполнять некорректные команды на сервере. А мы потом будем по логам это отслеживать и наказывать опосля. И судя по комменту про чит из Archeage это могут действительно так понять.
Я поэтому и решил откомментить дополнительно, что все подперто, выполнить некорректную команду не получится.
На самом деле это подперто и клиент никаких левых сообщений прислать не сможет.
В аннотации @ReplicateCmd указывается уровень доступа клиентской команды. Когда команда приходит на frontend, её уровень сразу же сверяется с уровнем доступа аккаунта, и при несоответствии она не будет выполнена и еще в лог напишут, что была попытка взлома.
Поэтому даже если игрок сумеет с клиента отправить какой-то чит, он не пройдет, так как у его аккаунта недостаточно прав на сервере.
Ну например, просто на эмоциях.
Есть люди, которые умеют отделить эмоции от бизнеса, а есть которые нет.
Че-то накипело, че-то недодали, какие-то обиды — вот и выплеснулось.
Если рассуждать рационально, то ссориться ему с мейлу смысла нет абсолютно никакого.
То что там называется «поиск» на самом деле не совсем поиск (и уж тем более не поиск ключей), а фактически выбор свойств желаемого.
То есть вот надо мне 15 января попасть из Москвы в Стамбул, я говорю сервису: когда, откуда и куда. Сервис показывает варианты. Все быстро и просто.
А концепция «первый экран приложения содержит готовые предложения, а не фильтры.» — это как раз рекламный bullshit, который не нужен пользователю. Ему не надо «на море» и «в горы». Пользователь, пришедший на авиапоисковик, уже знает куда и когда ему надо.
Поэтому первая страница должна содержать именно параметры запроса.
Мне этот подход скорее напоминает checked exceptions в java.
То бишь есть обычные exceptions, а есть checked exceptions.
Есть обычные коды возвращаемых ошибок, а тут checked коды.
В обоих случаях авторы фичи преследуют благую, казалось бы, цель: сделать возврат ошибок более явным, чтобы было понятно какие ошибки откуда берутся и их было сложнее проигнорировать.
Но сейчас, годы спустя, checked exceptions считается неудавшимся дизайном. Например, в том же C# от них осознанно отказались.
Здесь очень похожая ситуация, форсирование обработки, только механизм передачи сделан не через исключение, а через возвращаемое значение.
С долгосрочностью/краткосрочностью совсем не понятно. Что является осью времени, на которой мы измеряем эту долгосрочность? Работа программы? Жизнь программиста? Развитие IT индустрии?
А комментарии же уже после идут, отдельно. Извиняюсь, если оскорбил.
Однако бывают код, и это отнюдь не редкость, а вполне распространен на практике, в котором интенсивность содержания ошибок высокая. И с этим тоже надо что-то делать. Собственно я именно про такой код и задал вопрос.
В случае исключений до самой main падать не нужно. Обычно используется паттерн с большим try catch, наложенным на какую-то высокоуровневую операцию, который ловит все подряд. Ну тот же пример с web server, который генерит страницу. В процессе генерации страницы может случится всякое, ведь он же в том числе ходит за данными и во внешние источники. Но что бы ни случилось, обработка будет одна и та же: пользователю отдаем страницу 500, а техническому специалисту печатаем текст ошибки в лог.
Паттерн отлично работает, причем web сервер лишь пример, его можно применять еще много где.
Вот это действительно удобный подход, который позволяет программисту писать простой линейный код и снимает с него головную боль обработки бесчисленных fail path, которые случиться во время генерации. Соотношение код обработки ошибок/основной код сведено к минимуму.
Но если оказывается, что основная схема неудобна, то есть опасность что пользователь перейдет на вспомогательную, но более удобную для него.
Например, на все нужные ему стандартные пакеты напишет врапперы, которые превратят error в panic, забьет на инновацию языка авторов и будет работать по старому, с исключениями. Можно даже сделать библиотеку error2panic, выложить в opensource и она будет пользоваться популярностью.
Да, это хорошо, что язык предоставляет возможность обойти авторскую задумку и работать по старому, но мне все-таки интересно, можно ли удобно пользоваться новым способом.
После каждого вызова писать if r.err — это не выход, это принять страдания и смириться. Но ведь тут речь идет об удобстве, о том что простой и удобный синтаксис будет подталкивать программистов к правильному написанию программ.
Я всецело согласен с тезисом, что простота и удобство синтаксиса является мощным мотиватором для программистов, но я вижу, что обработка ошибок в Go создает огромную проблему, которая перекрывает все преимущества такого подхода. И решения этой проблемы я пока не вижу. Поэтому исключения для меня пока что выглядят куда проще и удобней, чем этот механизм.
Но вообще этот вопрос настолько важен, что мне кажется в статье про «серебряную пулю для обработки ошибок» нельзя это не упомянуть. Это я, разумеется, не Вам, а автору статьи.
Что касается решения, которое изложено в ссылке, то оно не является полным решением проблемы
1. Что делать, если мне все-таки нужно поведение, когда, при возникновении ошибки в очередной строчке, мне нужно сразу же завершить выполнение фрагмента? А отложить ошибку в сторону и проверить в конце нельзя, так как остаток фрагмента кода будет работать с битыми данными, а это плохо.
2. Предлагаемый в ссылке паттерн на самом деле сводит основное рекламируемое свойство Go на нет: программист в этом паттерне волен легко проигнорировать ошибку. То есть это уже не будет иметь никаких принципиальных преимуществ над обычными кодами возврата.
Как раз таки очень часто встречается. Представьте себе например, что вы работаете с базой. Или с сетью. И вот у вас кусок кода который в каждой строчке в эту базу или сеть лазит. И из каждой строчки потенциально может вылететь IOException.
Не имея возможности завернуть этот кусок кода в единый try catch, проверяя ошибочный результат на каждую операцию, вы просто задолбаетесь.
А код распухнет вдвое, его логику будет сложнее читать из-за этих if err != nil на каждой второй строчке.
Просто по этому абзацу может создаться ошибочное впечатление, что если взломать сетевой протокол, то можно выполнять некорректные команды на сервере. А мы потом будем по логам это отслеживать и наказывать опосля. И судя по комменту про чит из Archeage это могут действительно так понять.
Я поэтому и решил откомментить дополнительно, что все подперто, выполнить некорректную команду не получится.
В аннотации @ReplicateCmd указывается уровень доступа клиентской команды. Когда команда приходит на frontend, её уровень сразу же сверяется с уровнем доступа аккаунта, и при несоответствии она не будет выполнена и еще в лог напишут, что была попытка взлома.
Поэтому даже если игрок сумеет с клиента отправить какой-то чит, он не пройдет, так как у его аккаунта недостаточно прав на сервере.
спасибо
Есть люди, которые умеют отделить эмоции от бизнеса, а есть которые нет.
Че-то накипело, че-то недодали, какие-то обиды — вот и выплеснулось.
Если рассуждать рационально, то ссориться ему с мейлу смысла нет абсолютно никакого.
А еще перед входом позвонила жена и сообщила, что наш любимый хомячок Кеша умер…