1. Java / Говнокод #21732

    −51

    1. 1
    2. 2
    3. 3
    public void read(InputStream is) throws Exception {
            ...
        }

    Когда человек совсем не уверен в себе

    Запостил: krokozyabr, 27 Ноября 2016

    Комментарии (206) RSS

    • Быть может, программист хотел обработать исключение в этом методе.
      И вообще, что за манера, кидать одну строчку кода!
      Ответить
    • Как минимум InputStream бросает IOException. Фиг знает что еще содержится в этом методе.
      Ответить
      • > Фиг знает что
        Вот именно! А клиенту метода теперь придётся ловить (или прокидывать дальше) этот сраный экцепшен, с которым он ничего путнего сделать не сможет.
        Ответить
        • Как жаль что никто на свете не умеет в чекд эксепшены
          Ответить
          • Да их даже сами разрабы жабы не осилили.
            Ответить
            • не все. В некоторых местах (стримы, parseInt) они почти в тему
              Ответить
              • Ага, и в этих стримах они сами из-за них и обосрались (с RuntimeException не возникло бы желания задавить исключение в close).

                http://govnokod.ru/14254
                Ответить
                • да, в клозе обосрались, не спорю)))
                  В апаче коммнос даже closeSilently завезли

                  но ты и сам контракт нарушил: зачем ты клозишь стрим после IOException?
                  Ответить
                  • > контракт нарушил
                    Ткни носом, где. Разве что flush() не позвал перед close(). Но кто ж знал, что close() у FilterOutputStream молча жрёт исключения (хоть и throws IOException)...
                    Ответить
                    • обосрался
                      Ответить
                      • Лол, они таки пофиксили! Это из какой версии JDK? Восьмёрка поди?
                        Ответить
                        • ровно то, что ты написал, только в синтаксе восьмой джавы)

                          Это не ты контракт нарушил, а джависты: нельзя ничего делать со стримом после того что он кинул exception.

                          Ну и пидары-же
                          -------
                          или не пидары?

                          из close полетит excception?
                          Ответить
                          • Хуй с ним, с close(), код из восьмой хотя бы исключение от flush не жрёт... По крайней мере не получится молча проебать хвост файла как в 6-7. Так что в восьмёрке тот баг таки пофиксали.
                            Ответить
                            • Именно что НЕ жрет.

                              Сам попробуй
                              // write your code here
                                      FileInputStream s = new FileInputStream("c:\\HaxLogs.txt");
                              
                                      try (FileInputStream s2 = s) {
                                          throw new IOException("SD");
                                      }
                              
                                  }


                              А раз нежрет то и проблемы нет. Ща проверю была-ли она в седьмой
                              ------

                              Да, в седьмой именно так)


                              Ну ок, значит стримы научились юзать только к восьмой джаве
                              Ответить
                              • 6-7 жаба сожрала экцепшн, проверь.
                                Ответить
                                • жрало, ты прав)

                                  Выходит что в 6-7 джаве джависты сами насрали на свой контракт
                                  Ответить
                • нельзя обосраться.... но мы обосрались..))
                  Ответить
                  • Это были лихие девяностые и мы обсирались как могли.
                    Ответить
                    • У бомбы два провода - красный и синий. Не тот перегрыз и не станет России. А цыферки к нолику ближе и ближе. Во взмокшей ладони дрожат пассатижи. Застыла отчизна в погибельном трансе, Осталась секунда последнего шанса, Простая секунда, ничтожная малость. Нельзя обосраться, нельзя обосраться... И мы обосрались...
                      Ответить
                      • Красная армия сильная армия.
                        Смелая армия просто геройская.
                        Непобедимейшее войско.
                        В самом жестоком бою.

                        Припев:
                        А я обосрался в строю!

                        Все коммунисты и все комсомольцы.
                        Нужно подохнуть вперед добровольцы.
                        С песнями рота идет.
                        Только вот я не пою.


                        Припев:
                        Я обосрался в строю!

                        Родина мама спи не ворочайся.
                        Сыны твои гордо на стреме стоят.
                        Дали мне тоже большой автомат.
                        Стой говорят я стою.


                        Но вот обосрался в строю
                        Ответить
            • > Да их даже сами разрабы жабы не осилили.

              Вообще говоря, чекед-эксепшены -- принципиально унылое говно и попоболь. Их невозможно готовить правильно, нету языковых средств.

              Вот хочешь ты, к примеру, написать функцию высшего порядка, в которую коллбэк передается. Какое исключение должна кидать эта функция высшего порядка? Это зависит от того, что кидает коллбэк. Как в языке выразить мысль, что метод кидает то же самое исключение, что кидает его функция-параметр? Никак.

              Разве джависты пишут функции высшего порядка, спросите вы? Конечно пишут, только не знают об этом. Особенно, теперь, когда им лямбды с потоками подарили.

              Помню как-то визитор по простенькому "AST" запилил. Какое исключение нужно бросать из visit у объекта? А хрен его знает. Зависит от того, что бросает визитор.
              Захотел сконвертить дерево в JSON или распечатать в поток -- пиши унылые обёртки, которые конвертируют IOException во какой-нибудь специальный RuntimeExeption, и обёртку, которая достаёт родное исключение обратно.

              Лютое количество бойлерплейта для простой, казалось бы, задачи.
              Ответить
              • Смысл чекдов был в том, что метод может в рантайме понять что не может выполнить свою работу, и должен тебе как-то об этом сигнальнуть. Понятно что можно сделать это вручную:

                1) выйти из метода

                2) вернуть null или передать ссылку на результат (ах да, в жабе так нельзя), но это не заставит тебя проверить результат и можно легко проебать ошибку, да и писать 10 ретурнов не всегда комильфо.

                Если в рантайме у тебя отвалился диск или удаленный сокет или от пользователя пришел мусор, то эксепшен будет ебать мозг пока его либо его ЯВНО не поймают, либо он угандошит весь тред (ну или весь реквест в случае серверов), и это очень круто, просто у этого есть одно узкое применение.

                Джависты пишут функции (особенно с тех пор как туда завезли лямбды), но вот именно там чекдэксепшены красиво не заюзать, увы. Это проёб.

                Рантайм эксепшены вообще нужны для совсем другого, они просто случайно "так же называются" и сигнализируют о нарушении контракта. Их не надо ловить (разве что если они летят из плагина) а надо пиздить программиста по голове. В идеале они вообще не должны быть Exception, а должны быть Error
                Ответить
                • Можно подумать, я не знаю, для чего джависты придумали чекед-исключения. Сказка про иерархию исключений в жабе у любого зелёного джуниора от зубов должна отскакивать.

                  Проблем от них гораздо больше, чем пользы, вот в чём поинт. Нормальные пацаны не выпендриваются, не плодят лишные сущности и энкодят ожидаемые ошибки в типе возвращаемого значения.
                  Ответить
                  • >>энкодят ожидаемые ошибки в типе возвращаемого значения.

                    Тогда нужно на выбор
                    1) везде вертать туплу (Pair<Result, Error>)
                    2) в классе Object сделать поле lastError (щтоб он автоматом везде был)
                    3) научиться принимать указатель на объект чтобы заполнять его ошибкой.

                    Третий пункт очень любят яблочники в Objc:
                    NSError error;
                    NSFooBarBuz(42, &error);
                    if (error) {
                     //обосратушки
                    }



                    Какой из этих вариантов тебе менее противен? Ну или предложи свой
                    Ответить
                    • Говорю же, в типе возвращаемого значения указывать

                      StatusOr<T>
                      https://github.com/google/lmctfy/blob/master/util/task/statusor.h
                      Or_error в Ocaml, MonadError в Haskell.

                      Подход Go тоже вполне сносен.
                      Ответить
                      • StatusOr<T> -- по сути это мой вариант с туплой, просто более красивый, и в отличии от туплы у него есть отличный getValueOrDie, то-есть если там ошибка то всё упадет. Мне нравится.

                        Я подумаю еще до чего доебаться)
                        Ответить
                        • В Folly тоже похожий класс есть
                          https://github.com/facebook/folly/blob/master/folly/Try.h
                          Александреску про него как-то рассказывал
                          https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C
                          Ответить
                          • >>2012

                            Ох, сколько же времени прошло прежде чем люди поняли как правильно хендлить ошибки, да?

                            Тернист путь от errno/GetLastError
                            Ответить
                      • Ты просто наверное только факториал написал на Го.
                        Ну в Го вообще ничего хорошего нет, кроме горутин. Но ошибки там - это вообще эпический пиздец. Это так плохо, что даже Вижуал Басик покажется нормальным языком.
                        С другой стороны, на Го пишут либо дети которые хотят (хотели) прославится на Гитхабе, либо люди, которые повелись на красивую рекламу, и теперь не знают, как от этого говна избавиться. Все без исключения библиотеки на Го такого хуёвого качества, что даже Нода и ПХП на их фоне выглядят надежными и провереными временем.
                        Посмотреть на код того же Докера, etcd, Тераформ. О, Тераформ, это отдельный пиздец, который даже в горячечном бреду невозможно представить. Так можно в кровавых слезах утонуть. И не в последнюю очередь изза "работы с ошибками".

                        Начнем с того, что, если по-честному, в Го нет ошибок, как концепции. Есть какая-то хуйня под названием error, которя никого ни к чему не обязывает. И есть убогий механизм для работы с крешами програмы, который даже до уровня trap в Баше не дотягивает. И это, блять, при активно использующейся многопоточности и отсутствующем отладчике.
                        Изза того, что механизма бросания ошибок нет, нет и стектрейсов, и каждая библиотека дрочит как хочет, но в 90% случаев стектрейсов просто не будет. А в остальных 10% они будут указывать в произвольные места в програме.
                        Изза отстутсвия каких либо средств для работы с языком, однострочники в Го разрастаются в полотна бессвязных if err != nil { return err }. Статистика по моему проекту:

                        $ find ./src -type f -name '*.go' -exec grep 'if err != nil' {} + | wc -l
                        9292
                        $ find ./src -type f -name '*.go' | wc -l
                        543

                        А вот билт-ин говно:
                        $ find /usr/local/go/src -type f -name '*.go' -exec grep 'err != nil' {} + | wc -l
                        8049
                        $ find ./src -type f -name '*.go' | wc -l
                        2498


                        Из нашего отдела люди готовы уходить с понижением зарплаты туда, где пишут на Питоне, лишь бы только это говно не видеть.
                        Ответить
                        • Я не спец в го, но если он не нравится wvxvw , то его стоит попробовать.

                          >>Из нашего отдела люди готовы уходить с понижением зарплаты туда,
                          Когда я работал программистом в маленькой психиатрической больнице (С)
                          Ответить
                        • > Ты просто наверное только факториал написал на Го

                          Вообще говоря, нет, не факториал. Веб-приложение -- аналог https://kapeli.com/dash, которое индексирует локальные доки (либу для парсинга я писал на сишке, в го использовал FFI) и позволяет делать fuzzy-поиск (на биграммах) по документации с динамической подгрузкой результатов. Честно говоря, я в основном упирался в тормознутость стандартных структур данных из-за отсутствия нормальных шаблонов. Ручной инлайнинг ускорил тогда мой поиск в 8 раз.

                          В последнее время я мало пишу на Го (в основном на C++), но воспоминания в основном положительные. В плане обработки ошибок подход у нас аналогичный.

                          > нет и стектрейсов

                          Это большая проблема, очень серьёзная. В C++ тоже стектрейсов нет из коробки. Можно сбоку прикрутить при большом желании, но большинство этим не занимается.

                          Когда пишешь асинхронный код, стектрейсы вообще бесполезны -- коллбэки дёргаются из реактора, интересного в них ничего не увидишь.

                          > где пишут на Питоне

                          О да, больше всего на свете я "люблю" программы на питоне, которые в любой непонятной ситуации кидают в меня Key/Value/WhateverError. Возможно, стектрейс поможет разработчику ткнуть пользователя в нужную строчку документации или понять, где он накосячил в типах, но никак не поможет ему побороть свою неспособность нормально обрабатывать ошибки. Пользователю они скорее мешают.


                          Универсальное средство обработки ошибок -- это миф, исключения им не являются.
                          Ответить
                          • Хорошие программы на python выдают хорошие сообщения об ошибках.

                            А плохие программы (в случае мусора на входе) дают говно.

                            Нативная программа дает General Protection Fault.

                            Программа на питоне дает KeyError.

                            Жаба дает NPE и 150 строк маловразумительных трейсов

                            Итд
                            Ответить
                            • > Хорошие программы на python выдают хорошие сообщения об ошибках.

                              Охотно верю. Жаль, что мне такие практически не попадались.
                              Ответить
                              • Питона много в дроппобксе. Ты хоть раз видел KeyError на сайте дропбокса?
                                Ответить
                                • > Ты хоть раз видел KeyError
                                  Да ты их даже в пыхе не увидишь, если сервер правильно настроен... Кто в 2016 году ошибки в браузер срёт?
                                  Ответить
                                  • > Кто в 2016 году ошибки в браузер срёт?
                                    Яндекс.Музыка
                                    Ответить
                                    • Не всегда. Иногда Яндекс.Музыка не играет, ничего не сообщая пользователю.
                                      Ответить
                                  • https://www.google.ru/search?q=warnong+invalid+argument+suppli ed+for

                                    отак с ходу
                                    https://toster.ru/q/61278
                                    Ответить
                              • Неясно, что вообще писать в случае ошибки программиста.
                                Это задача того же уровня, что и построение полного (совсем полного) списка уязвимостей системы.
                                Ответить
                                • > в случае ошибки программиста

                                  Я уже говорил, что не против исключений в случае ошибок программиста (в go для этого есть panic).
                                  Правда, в C++ для этого полезней крэшится -- можно потом в core-дампе как следует поковыряться, ибо стэк-трейс зачастую не содержит информации, которая поможет исправить ошибку.
                                  Ответить
                                • >>что вообще писать в случае ошибки программиста.
                                  "программа содержит ошибку и будет закрыта, напишите программисту"
                                  Ответить
                            • > А плохие программы (в случае мусора на входе) дают говно.

                              Go сам по себе программистов не исправит. Тот, чья стратегия обработки ошибок заключалась в ловле всего что можно в main и печати в stdout, так и будет писать при любом удобном случае if err != nil { return err } и ругать Go. Иногда return err -- это именно то, что нужно. Часто имеет смысл вернуть новую ошибку, с описанием того, что пытались сделать, с какими аргументами, и почему не получилось. "Exception translation", только с менее громоздким синтаксисом и более полезными для пользователя сообщениями.
                              https://blog.golang.org/errors-are-values
                              Ответить
                          • Лол. В С++ тоже нет стектрейсов? Да ну? Сравнил говно с поносом. Какя разница, что там есть в С++.

                            А про асинхронный код: да, насмешил. Бесполезные говоришь. А что ошибки никогда искать и исправлять не приходилось? Просто потому, что в Го этого практически нереально добиться, не переписав рантайм с нуля - тебе просто в голову не прийдет, что это вообще возможно. А оно ведь все тут, рядом, и существует уже много лет.

                            А ты не подумал, что над разработкой програмы, и над чтением ее стектрейсов вызваных некорректным поведением програмист проводит 99% от рабочего времени? И что без этой информации, програма вообще никогда не попадет к твоему чисто теоретическому заказчику?
                            В соседнем отделе, продукт, аналогичный нашему писало два человека на Питоне. (В моем отделении нас было шестеро, но двое уволились, и еще двое перешли в другие отделы). Они все сдали и уехали в Аргентину на месяц курить гашиш, а у нас что ни неделя, то добалвяется 100-200 if err != nil. Потому, что билт-ин библиотека - говно. Чужие библиотеки - говно. В своем коде невозможно проследить логику выполнения изза того, что приходится бороться с некорректной работой всего остального.

                            Я молюсь чтобы меня перевели либо на Питон, либо на Руби. Я бы даже на Яве писал, лишь бы это говно больше никогда не видеть.
                            Ответить
                            • --Language1 лучше чем Language2
                              --Докажи
                              --Ну у нас на Language1 программу написали быстрее, чем на Language2.

                              У Сёмы достойный конкурент
                              Ответить
                              • Бароп, снова ты на связи, дегенерат?

                                >--Ну у нас на Language1 программу написали быстрее, чем на Language2.
                                Значит она им дешевле вышла, понимаешь? ДЕНЕШКИ. В мире апинсорса такого нет.
                                Ответить
                                • Ну да, это вполне же твоя логика.

                                  --ахахаха openssl не используют в серьезных конторах
                                  --докажи
                                  --ну я слышал что в amazon его не используют

                                  --хахаха l2tp не настроить в линуксе
                                  --докажи
                                  --ну я чатился с долбоебом который не осилил l2tp в freebsd

                                  Вы с wvwvwcwv два сапога пара
                                  Ответить
                                  • >-хахаха l2tp не настроить в линуксе
                                    >--докажи
                                    >--ну я чатился с долбоебом который не осилил l2tp в freebsd
                                    Сама додумала, обезьянка? Где я это утверждал?

                                    >--ахахаха openssl не используют в серьезных конторах
                                    >--докажи
                                    Хром. Существование форков.
                                    Ответить
                                    • >>Где я это утверждал?
                                      http://govnokod.ru/21736#comment360570

                                      >>Хром. Существование форков.
                                      Cryptography Functions из Windows не используются в Chrome под Mac OS X. Следовательно, Windows Crypto API не используется в серьезных проектах.
                                      Бугага.
                                      Ответить
                                      • Потому что он не кроссплатформенный, дурачок. Алсо завези туда какой-нибудь гост.

                                        >http://govnokod.ru/21736#comment360570
                                        Где ты там прощел "l2tp не настроить в линуксе" и "l2tp в freebsd"? Конкретно эти цитаты приведи, питушок косоглазый.
                                        Ответить
                                        • Вся твоя школолошная говнопаста, которую ты сюда зачем-то припер, состояла из описаний страданий петушка, который не мог в линуксе и то и сё.

                                          В том числе он не мог в L2TP. Когда я попыталася рассказать тебе о прелестях L2TP на винде, ты начал нести нелепые отмазки про какого-то неосилятора, который не смог L2TP во фрибзд.

                                          Тут дело даже не в том, что FreeBSD не имеет отношения к линуксу (незнание этого факта я тебе прощаю, ты и более простые вещи не знаешь), а в том что для доказательства утверждения "Foo это сложно" ты приводишь аргумент "питушок не смог Foo".

                                          Это характеризует только петушка. Ну и тебя, как человека который с ним общается.
                                          Ответить
                                          • С возвращением, Ваше Высочество. Так их, анскилябр этих.
                                            Ответить
                                • >>Значит она им дешевле вышла, понимаешь?
                                  Мне даже лениво объяснять насколько не в тему тут это твое глупое замечание.
                                  Ответить
                                  • >ДЕНЕШКИ. В мире апинсорса такого нет.
                                    Ясно.
                                    Ответить
                                    • Подобные представления об опенсорсе я слышал в 1999-м году от троллей, а с тех пор уже и не слышал.

                                      Наверное нужно последние 15 лет прожить в пузыре, чтобы всерьез думать что в линуксах драйверы компилируют вручную, а опенсурсные разработчики не получают зарплату.

                                      Люди в RedHat, Apple и Google, разработчики Android, Darwin, llvm -- им всем ужасно приятно будет узнать что они не получают зарплату.
                                      Ответить
                                • > программу написали быстрее
                                  > значит она им дешевле вышла
                                  Ахуенная логика.
                                  Ответить
                                  • Мням, что не так?
                                    Ответить
                                    • > что не так
                                      В выводе, достойном британских учёных - "если программу написали быстрее, то она им дешевле вышла".
                                      Ответить
                                      • То есть про то что время программистов оплачивается, причем по постоянной ставке, ты не слышал?
                                        Ответить
                                        • Сём, если ты когда-нить в жизни будешь работать программистом ты узнаешь еще что бывает поддержка программ, и она тоже не бесплатна.

                                          И что программисты в мире опенсурса тоже получают зарплату.

                                          А потом ты научишься читать, почитаешь первоначальный высер своего брата по разуму, и узнаешь что деньги и скорость написания тут вообще не причем
                                          Ответить
                                          • > тоже получают зарплату
                                            И что зарплата у разных программистов, внезапно, разная... И что сложность программ могла отличаться...

                                            > она тоже не бесплатна
                                            Скупой платит джважды ;)
                                            Ответить
                                          • >бывает поддержка программ, и она тоже не бесплатна.
                                            Как на это влияет ЯП? Я имел в виду написать ту же программу с тем же качеством. Если ее можно написать быстрее, то почему нет?
                                            Ответить
                                        • > причем по постоянной ставке
                                          Т.е. премий и повышений у вас там не бывает? :) Грустно как-то...
                                          Ответить
                                          • У меня не бывает премий! И повышений не предвидится! Хнык :'(
                                            Ответить
                                            • работаешь плохо?
                                              Ответить
                                              • Говено работаю, да. Хотя мне кажется, что это не моя вина.
                                                Ответить
                                                • > Хотя мне кажется, что это не моя вина.

                                                  Go виноват?
                                                  Ответить
                                                  • Начальство. Задач нет, не дают проявить себя на поприще разработки ПО.
                                                    Ответить
                                                    • не такая и редкая ситуация

                                                      но я бы не сказал, что сейчас на рынке труда всё плохо
                                                      Ответить
                                                    • попробуй сменить контору
                                                      Ответить
                                                      • Если бы знал хорошие варианты, уже сменил бы. Не хочется пересаживаться с пик точеных на хуи дроченые.
                                                        Ответить
                                                        • Странная логика.

                                                          Ну поищи контору которая тебе нравится, узнай что ей надо и выучи.

                                                          А то вот так люди страдают до тридцати пяти лет, а потом оказывается что лет им уже много, а кроме просиженных штанов опыта и нет.
                                                          Ответить
                                                          • А хуй знает, что им надо. Я тут собеседовался в одну симпатичную контору. Поспрашивали баяны про сортировку и т.п., я поотвечал. Перезванивать не стали. Хнык, в общем.
                                                            Ответить
                                                          • Что за магическое число - 35?
                                                            Ответить
                              • А как правильно языки сравнивать?

                                По количеству фич? По количеству программистов? По количеству проектов? По математической каноничности? По строчкам кода для решения эталонной задачи? По количеству правил грамматики?

                                Тут хотя бы человек публикует данные, каким-то образом относящиеся к реальности.
                                Ответить
                                • >>По количеству фич?
                                  да
                                  >>По количеству программистов?
                                  нет
                                  >>По количеству проектов?
                                  да
                                  >>По математической каноничности?
                                  не очень
                                  >> По строчкам кода для решения эталонной задачи?
                                  да
                                  >> По количеству правил грамматики?
                                  не очень

                                  >>каким-то образом относящиеся к реальности.
                                  Один мой знакомый ходил в синей кепке, и его сбила машина.
                                  А другой ходил в красной и его не сбила.

                                  Отсюда я делаю вывод что синие кепки носить опаснее.
                                  Ответить
                            • > А что ошибки никогда искать и исправлять не приходилось?

                              Собственно, это основная часть моей работы -- чинить нетривиальные ошибки. Когда люди нормально обрабатывают ошибки, ты либо сразу понимаешь, в чём проблема (даже не открывая сорцов), либо вставляешь кусок текста ошибки в git grep/code search и практически сразу находишь нужное место.

                              Кстати, ты может раньше не замачал... Твои доводы на 96% состоят из эмоций и не содержат информации для размышления.
                              Ответить
                              • Так ты там на багфиксе сидишь? Лол.
                                Ответить
                                • Конечно. В гугле есть специальные отделы багинтродьюсеров и багфиксеров.
                                  Багинтродьюсеры делают баги, а багфиксеры их правят.
                                  так и живут.
                                  Ответить
                                  • как всегда, ты сарказмируешь не в тему а в лужу
                                    Ответить
                                    • Просто было трудно удержаться увидев такой наивный высер
                                      Ответить
                                      • Что в нем наивного, бароп? Для тебя сикрет, что многим программистам задачи спускает начальство, и иногда это только баги, которые надо пофиксить?
                                        Ответить
                                        • Если одни программисты занимаются исключительно багфиксом, то логично предположить что другие занимаются исключительно багмейкерством. Так-ли это, хуесто?
                                          Ответить
                                          • Нет, просто у тебя с логикой проблемы (тоже не в первый раз замечаю).
                                            Ответить
                                            • Зато с логикой отлично у тебя. Из того факта что Кашицин фиксит баги ты сделал вывод о том, что "задачи спускает начальство, и иногда это только баги".

                                              Видимо ты пытаешься перенести свое доширачерство на галерах на гугл.
                                              Этакий обратный карго-культ.
                                              Ответить
                                • > Так ты там на багфиксе сидишь? Лол.

                                  Я каждое утро прихожу на работу, открываю логи сервиса, и создаю баги на все крэши и ERROR записи, которые считаю ошибкой. Часть назначаю на ответственных, часть чиню сам.
                                  Мне вообще стрёмно писать новый код, пока старый делает хрен пойми что.

                                  Ты так не делаешь, @subaru?
                                  Ответить
                                  • > Каждое утро я прихожу на работу, открываю логи сервиса, и создаю баги на все крэши и ERROR записи, которые считаю ошибкой.
                                    Прям начало копипасты о Воване.
                                    Ответить
                                  • Не делаю. У меня и так полный бэклог унылых багов, от которых уже тошнит. Но ты молодец.
                                    Ответить
                              • Да ну? "нормально обрабатывают ошибки" - это не эмоциональный аргумент, чтоли? Это просто пиздежь бессмысленный. Который порисходит от самолюбования и непонимания предмета разговора.

                                По поводу метрик, и почему раньше сделаный продукт в соседнем отделе - это показательно.
                                Потому, что, как я уже говорил, продукт аналогичный. Наш отдел пишет инфраструктуру для тестов, другой отдел пишет инфраструктуру для самой системы. Под инфраструктурой понимается установка, настройка, отладка, аггрегация статистики и первичный анализ.
                                Наши задачи очень похожи, и по объему и по назначению.

                                Код написаный на Питоне вызывает минимум проблем: за последние три месяца в ночных сборках + тестах этот код проявил себя всего два раза (один раз забыли добавить какую-то программу в системный путь, и другой раз поменялся механизм раздачи SSH ключей в кластере, который они не предусмотрели).

                                Код написаный на Го вызывает проблемы раз в два-три дня. С банальными ошибками, которые прошли мимо код-ревью потому, что на Го можно писать только говнопортянки, и просто нету достаточно человек, чтобы уделить достаточно внимания чтению этого бреда. Ошибки типа: после парсинга Ясона забыли проверить длину массива. Перепутали местами строчку с сообщением об ошибке и строчку, где предполагается, что ошибка уже обработана. Ну, и иногда билт-ин АПИ подсыпает всяких крашей в абсолютно безобидных местах. Типа "попытка закрыть уже закрытый канал, блять" - очень серьезная ошибка изза которой програма закрывается без строчки логов.
                                Ответить
                                • > "нормально обрабатывают ошибки" - это не эмоциональный аргумент, чтоли?

                                  Нет, я же написал, что понимаю под нормальной обработкой ошибок -- внятное семантическое описание проблемы, понятное пользователю, вместо унылых стектресов. Например, довелось мне как-то запускать чей-то питонокод, обучающий классификатор. Через пару минут работы обучателя вываливался невнятный стэктрейс из глубин skikit-learn с сообщением ValueError: 1 < 2. Оказалось, что обучающий набор был кривой и содержал только примеры с одной меткой. Нормальной обработкой ошибок я бы назвал сообщение "Your training set contains only 1 label, the classifier expects at least 2. Check your data." Это сообщение бы мгновенно указало мне на мою проблему, и мне не пришлось бы пару часов изучать кишки skikit, чтобы понять, как я пришёл к 1 < 2.

                                  > это показательно.

                                  Это было бы показательно, если одни и те же люди, имеющие одинаковую экспертизу в обоих языках, писали одно и тоже. Откуда мне знать, какие вы там профессианалы, если вы каналы по два раза закрываете.

                                  > парсинга Ясона забыли проверить длину массива

                                  В питоне такую ошибку, несомненно, невозможно допустить.

                                  > Перепутали местами строчку с сообщением об ошибке и строчку, где предполагается, что ошибка уже обработана.

                                  Исключения, очевидно, решают эту проблему.

                                  > безобидных местах. Типа "попытка закрыть уже закрытый канал

                                  Это в основном показывает, что вы не умеете в понятие "владение ресурсом". И да, это означает ошибку программиста.

                                  > програма закрывается без строчки логов.

                                  Чего? Паника происходит. Если вы не печатаете её в лог -- это ваша проблема.
                                  panic: close of closed channel
                                  Ответить
                                  • Та ладно, ты не знаешь, что слово "семантически" значит. Просто умного из себя строишь. А по сути просто хуйню какую-то пишешь. У тебя, блять, был стек трейс, по которому ты мог найти неработающий код, и попробовать использовать то место куда ты кушаешь для того, чтобы понять, что там случилось. Вот когда у тебя в коде 20% ошибок выглядят так: io.EOF, без стек трейсов. Вот тогда ты понимаешь, зачем нужны стек трейсы.

                                    Тебе о профессионализме не судить, если ты думаешь, что это очень нужный краш при повторном закрытии канала. Краш всей программы, Карл! Нахуй нужен такой close() в высокоуровневном языке с потоками и селектами? Просто у этих долбоебов "так получилось", вот поэтому так и работает. Они не планировали, не думали о том, как лучше сделать. Налабали какой-то хуйни и в продакшн. Благо, все, что они делают - для внутреннего пользования, а там видимо инженерам нечем руки занять, вот и тестируют. Вот и пишут ёба-недоинерпретаторы Питона на Яве для сборок своих проектов и подобную хуету.

                                    Я же говорю, что в Го эти тривиальные ошибки тяжело найти изза того, что код размазан на 100500 строк бессмысленной повторяющейся хуйни. Ревьюер не в состоянии читать одно и то же, и не ошибаться никогда.

                                    Да чего там дальше объяснять... Ну, вот, продукт "известной" компании. Типа хай-энд продукт. Семинары, платные специалисты, все дела:
                                    https://github.com/kubernetes/kubernetes/blob/master/cmd/kube-apiserver/app/server.go#L80
                                    Твои же братья-долбоебы написали. У меня просто руки опускаются, когда мне говорят, что мне нужно это говно использовать в своем проекте. Они, блять, ошибки все одного типа возвращают, принтэфами. Без стак трейсво. Полотно из функций на 200 строк. Пидарасы. Уебаны. Слов нет.
                                    Ответить
                                    • > Полотно из функций на 200 строк.
                                      Мне бы твои проблемы. У меня тут функции по 2к строк очень плохого спагетти. Хнык :'(
                                      Ответить
                                      • А давайте попросим страйкера сделать отдельный раздел, где мы будем ныть про наши галеры?
                                        Ответить
                                    • >>что это очень нужный краш при повторном закрытии канала. Краш всей программы, Карл!

                                      Попробуй PHP, серьезно. Там можно и файлы 2 раза закрывать, и к неинициализированным переменным обращаться.

                                      Главное собачку поставить в начале.

                                      Вообще управление ресурсами и памятью это скучно. Лучше всегда рандомно выделять память и освобождать её, захватывать ресурсы и отпускать. Пусть ЯП и его рантайм сам обо всем позаботятся
                                      Ответить
                                    • > Просто умного из себя строишь.

                                      Ну ок, давай посмотрим глазами трезвого человека на то, что ты написал.

                                      В соседнем отделе люди пишут на питоне, и не ноют, и вообще всё давно сделали. У вас много детских ошибок: потерянные проверки, перепутанные местами педали строки, не знаете, кто владеет каналами, не печатаете паники в лог. Вы ноете и хотите уволиться. И виноват в этом, разумеется, Go. Потому что там писать много надо.

                                      Нет, ну всякое бывает, я тоже раз в год continue в каком-нибудь цикле забываю в чейнджлисте на 100 строк, и ревьюер этого не замечает, но язык-то тут причём.

                                      > повторном закрытии канала

                                      Повторное закрытие канала в "в высокоуровневном языке с потоками и селектами" это потенциальный рейс кондишен. Вероятно, две горутины конкурентно гадят в один канал, и не знают, кто его должен закрыть. Лучше просигналить эту ошибку сразу, чем ждать, пока через полгода что-нибудь закрэшится при попытке записи в закрытый канал.
                                      Если ты так не считаешь, то вам следовало писать на PHP: там можно делить на нуль и игнорить ворнинги.

                                      > ошибки все одного типа возвращают

                                      И чем тебе помогут ошибки разных типов в этом случае? Ты напишешь код, который сам будет устанавливать отсутствующий сертификат, если получит MissingCertificateError? Видимо, тут все ошибки unrecoverable, код не сможет починить сам себя, требуется внимания программиста. На первый взгляд ничего откровенно плохого не вижу. В пистоне была бы такая же портянка, только отовсюду летел бы какой-нибудь KubernetesError или, ещё хуже, ValueError.
                                      Ответить
                                    • > тривиальные ошибки тяжело найти
                                      > ревьюер не в состоянии читать одно и то же
                                      Ну х.з. У нас вот тоже код с ручной обработкой ошибок (+RAII для всех ресурсов). Если кто-то где-то забывает обработать ошибку - на ревью это прям режет глаза, т.к. выбивается из общего стиля и нарушает однородность ;)
                                      Ответить
                            • > Потому, что билт-ин библиотека - говно
                              > Чужие библиотеки - говно
                              A bad workman blames his tools.
                              Ответить
                              • Я его понимаю. Когда какой-то плавающий баг раз в месяц роняет программу в кору, а стектрейс ведет в какие-то бустовые кишки, то у меня лично в такие моменты накатывает депрессия. А при попытке разобраться в сорцах этих бустовых кишков вообще повеситься хочется.
                                Как ты справляешься с такими ситуациями, борманд?
                                Ответить
                                • > в кору
                                  > стектрейс
                                  У тебя есть стектрейс и дампы. Мне бы твои проблемы...

                                  > Как ты справляешься
                                  Культурой кода - проверки указателей, ассёрты, RAII и т.п. Больше, походу, никак.

                                  З.Ы. Хотя, после проезда по памяти, все эти коры и бектрейсы - просто бесполезный мусор, показывающий на какой-нибудь невинный код...
                                  Ответить
                                  • Лол, а у тебя нет?
                                    Ты под ios пишешь чтоли? Это когда твоя программа упала у Васи и всё что ты знаешь это "твоя программа упала"?
                                    Ответить
                                  • > Культурой кода
                                    Ну это не очень полезный совет. "Чтобы программа не падала, надо просто не писать баги."
                                    Ответить
                                    • > не очень полезный совет
                                      Ну раз не хочешь ему следовать - пиши хуйню @ читай крешдампы до утра. Пока не обретёшь просветление.
                                      Ответить
                                      • > пиши хуйню @ читай крешдампы до утра.
                                        Use Erlang @ Let it crash
                                        Ответить
                                        • Да уж, хорошо что там ФП и вообще порог вхождения высокий, а то был бы идеальный язык для говнокодеров.
                                          Ответить
                                          • > и вообще порог вхождения высокий

                                            Я вас умоляю. У нас две недели даётся на изучение с нуля вместе со всем ФП. Потом, конечно, некоторое время на гк наблюдаются "фирменные ревью от Снаута".
                                            Ответить
                                        • > Let it crash
                                          У меня на прошлой работе гуйня для терминала так работала - сегфолтилась, супервизор её перезапускал, прога подтягивала стейт с сервака, обрабатывала кнопочки-датчики, отправляла стейт на сервак, рисовала новый фрейм, сегфолтилась... Сегфолт каждый кадр, но по ощущениям вполне нормально работало, просто трафика много на сервер. Заметил не сразу :)
                                          Ответить
                                          • А надо было разумный restart intensity и period в супервизоре установить!
                                            Ответить
                                            • > разумный restart intensity и period
                                              Тогда вообще бы не заметил?

                                              З.Ы. Супервизором там был тупой sh скрипт с бесконечным циклом :)
                                              Ответить
                                              • > Тогда вообще бы не заметил?
                                                Наоборот, через некоторое время супервизор отправил бы чайлда мыться под струю сам бы покрешился, ибо поддерживать сервис -- это хорошо, но поддерживать _неправильно_ работающий сервис -- немного другое.
                                                > Супервизором там был тупой sh скрипт с бесконечным циклом :)
                                                Это тогда не надзиратель, а сообщник.
                                                Ответить
                                                • > сам бы покрешился
                                                  Т.е. в итоге самый главный супервизор понимает, что жизнь - тлен. И делает харакири себе и всем оставшимся в живых?
                                                  Ответить
                                                  • > И делает харакири себе и всем оставшимся в живых?

                                                    Именно. Если не помогает даже, скажем, рестарт на уровне кластера, главный супервизор говорит, мол, "вызывайте этих говнокодеров из отпусков, выходных и заказывайте им ведро вазелина, а я отправляю трафик в другой дц и ухожу в спячку".
                                                    Ответить
                              • Ну да, потому что проще всегда перейти на личности и сказать "ты мудак" потому что тебе что-то не нравиться.

                                По-поводу чужих библиотек. Ну, взять тот же парсер для Ямла на Го. Это уебищная копи-паста из сишного кода, без понимания того, что происходит в оригинале. Он примеры с оф. сайта в половине случаев не может распарсить. А когда может - выбрасывает нужную информацию. Ну и кроме всего прочего - не потокобезопасный.
                                Есть, например генерилки для Трифта / Сваггера. Код сгенерированый для Трифта ни один линтер не пройдет, а кроме того, в сгенерированом коде не просто невозможна многопоточность, он вообще больше одного запроса одновременно обработать не может. В Сваггере сгенерированом полно string.ToUpper("POST") и т.п. хуйни. Они наверное вообще ни разу не смотрели на то, что генерировали. А до запуска дело вообще не дошло.

                                Из гугловского говна: реализация SFTP, но без сжатия. Зато они туда нахуярили асинхронную сборку и чтение файлов. Типа, можно читать файл одновременно с разных отступов. Но интерфейс у этого говна все-равно последовательный. Т.е. если попытаться патч написать для этого бесполезного говна, на это уйдет несколько месяцев.

                                А вообще, на говнокоде просто места не хватит рассказывать про всю уебищность библиотек на Го. Выше - только промиля из всего, что там творится.
                                Ответить
                                • Ну т.е. виноват не язык, а просто инфраструктура сырая (что вполне нормально для молодого и развивающегося языка).
                                  Ответить
                                  • З.Ы. К слову, тому же питону 25(!) лет.
                                    Ответить
                                  • А он сишные либы не умеет юзать что ли?
                                    Ответить
                                    • Умеет, но вроде через гланды. Я сам не гошник, но в каком-то докладе слышал, что там FFI вызовы через три пезды в отдельном потоке выполняются.
                                      У гошников явный тренд писать все снуля на го. У них даже собственная реализация tls на го вместо опенссл.
                                      Ответить
                                      • тсс
                                        никому не рассказывай что у жабы и дотнета тоже есть такой тренд.
                                        Ответить
                                  • А почему C#.NET моложе пыха, а при этом там и фреймворк и язык в тыщу раз лучше?
                                    Ответить
                                    • > моложе пыха
                                      Всего года на 3, если верить вики :)

                                      А насчёт того, что фреймворк лучше - только последние. Второй тем ещё говном был. А первый - имхо, даже хуже жабы.
                                      Ответить
                                      • Второй был не хуже шестой жабы, а то и лучше (генерики в рантайме).
                                        И уж конечно он в тысячу раз лучше пхп
                                        Ответить
                                        • >генерики в рантайме
                                          Зачем они нужны?
                                          Ответить
                                          • Ты не поверишь: чтобы чекать тайпы в рантайме, чтобы не ловить ClassCastException, чтобы кастовать в Array без бойлерплейта
                                            Ответить
                  • Кстати, а ты же там без исключений пишешь? Расскажи, как работается спустя пару месяцев. Как без стл живется? Как процесс разработки устроен? Слей инсайдов про борг и спаннер.
                    Ответить
                    • спорим, хуесто, он тебе ничего не расскажет?

                      В корпорации добра такие NDA что папа не горюй
                      Ответить
                      • Ну а вдруг) Хотя он и в прошлый раз неохотно рассказывал.
                        Ответить
                        • ну вдруг, да) Послушаем)

                          Я вот слыхал что там до такой степени своя атмосфера, что даже кодстайлы у них не всегда совпадают с оф. рекомендациями (типа питонячьего pep8)
                          Ответить
                          • Таки проигнорил похоже :-\
                            Ответить
                            • > Таки проигнорил похоже :-\

                              Не совсем понятно, что ты ожидаешь услышать. Всё, что я могу рассказать, уже давно и так опубликовано и широко известно (собственно, поэтому я и могу это рассказать).

                              Borg: http://research.google.com/pubs/pub43438.html
                              Spanner: http://research.google.com/pubs/archive/44915.pdf
                              Flume: http://research.google.com/pubs/pub35650.html
                              Bazel: https://bazel.build/
                              
                              C++ Guildeline: https://google.github.io/styleguide/cppguide.html
                              Python Guildeline: https://google.github.io/styleguide/pyguide.html


                              > Как без стл живется?
                              Кто сказал, что без стл? Либы тут отличные, кстати.

                              > Как процесс разработки устроен?
                              http://agileconsortium.pbworks.com/w/page/f/XR7+mstriebeck-ShtAddingProcess.pdf
                              Ответить
                              • Ну естественно я ожидал что-то, чего нет в этих статьях, каких-то охуительных историй и личных впечатлений. Та же статья про спанер вышла 4 года назад, с тех пор наверняка много поменялось.
                                Ну я в общем не настаиваю. Если нет охуительных историй, то и не надо.
                                Ответить
                                • А ты небочь пишешь на пхп за доширак в маленькой вебстудии, и по ночам мечтаешь о Гугле?
                                  Ответить
                              • >> With the help of an experienced agile leader (scrum
                                >> master, XP coach…) it was possible to carefully
                                >> introduce agile practices into Google

                                Круто:) Я единожды видел скрам в аутсорсе. Продуктовые компании редко его умеют. Гугл молодец
                                Ответить
                                • А я видел, как в продуктовой компании аджайл юзает... IT саппорт. Заставь дурака богу молиться.
                                  Ответить
                                  • страшно представить какой у них размер спринта
                                    Ответить
                                    • Три недели, всё по взрослому. Вот это называется менеджерская шиза.
                                      Ответить
                                      • --у меня сломалась мышь
                                        --добавили в беклог, попробуем впихнуть в следующий спринт на планировании

                                        Пленниг покер: сколько времени займет замена мыши?
                                        Ответить
                                        • Ну там речь была не про мыши, а про обслуживание/аппаратную перенастройку серверов в лабе, но суть ты понял . Людей спасала только система знакомств ^___~
                                          Ответить
                                          • но я видел и обратные случаи, где требования к софту были у программиста в голове, потому что их озвучили сегодня вечером по скайпу. И где программист выкладывал наживой сервер по FTP нетестированные патчи
                                            Ответить
                    • Ну я вот тоже без исключений пишу. Как-будто это что-то редкое и необычное.
                      Ответить
                      • довольно сложно это делать, когда стандартная библиотека и буст дизайнились с исключениями в уме (да, я знаю, что в гцц можно выключить, и стл начнет абортиться вместо исключений, но это сомнительный костыль).
                        Ответить
                        • > стандартная библиотека
                          > с исключениями в уме

                          Лол, в каком месте? Весь STL exception-agnostic, iostreams вообще унылое говно на флажках.
                          Ответить
                          • > Лол, в каком месте?
                            Все контейнеры stl, которые никак не могут просигналить об out of memory. Разве что тупо abort()'ом.
                            Ответить
                            • Ну как раз bad_alloc вменяемо обрабатывать только ембедщики и умеют кажется. А вот всякие at() можно было бы и без исключений сделать.
                              Ответить
                              • > bad_alloc вменяемо обрабатывать
                                А на линупсе оно вообще редко прилетает... Скорее OOM киллер кого-то убьёт в подворотне, чем ядро признается в недостатке памяти.
                                Ответить
                                • Наш научный код падает по bad_alloc примерно в трети случаев. В остальных - oom_killer приходит, да.
                                  Ответить
                            • > которые никак не могут просигналить об out of memory

                              std::set_new_handler
                              Ответить
                              • Туда что-то осмысленное можно засунуть кроме лога и/или аборта? :)
                                Ответить
                                • запуск сборщика мусора
                                  Ответить
                                • > Туда что-то осмысленное можно засунуть кроме лога и/или аборта? :)

                                  Вызов Borg, который перезапустит бинарник на машине с большим кол-вом RAM.
                                  Ответить
                                  • Ну можно ещё подёргать какие-нибудь коллбеки у других подсистем, чтобы они поделились памятью.
                                    Ответить
                                    • https://developer.apple.com/reference/uikit/uiviewcontroller/1621409-didreceivememorywarning?language=objc :)
                                      Ответить
                          • Стандартная библиотека - это не только стл. Там дохуя кто эксепшоны бросает. Вот тебе чиста для примера, чтобы ты понял, о чем я: http://ru.cppreference.com/w/cpp/string/basic_string/stol
                            Ответить
                            • Ок, допустим, stol кидает исключение. Я бы сказал, что он такой просто нафиг не нужен.

                              Какова вероятность, что некая строка является валидным числом? Небольшая. Значит, ошибка в этой функции вполне ожидаема. Если ошибка ожидаема, какое-же это тогда "исключение"?

                              Разумеется, для этого есть вменяемые эквиваленты, возвращающие StatusOr<T>.
                              Ответить
                              • Напомню, что тут речь не про идеальный способ работы с ошибками, а про то, что со стандартной библиотекой жить без исключений скорее нельзя, чем можно.
                                Ответить
                                • > что со стандартной библиотекой жить без исключений скорее нельзя, чем можно.

                                  Ну ок, ты нашёл пару функций в стандартной библиотеке, которые зачем-то кидают исключения.

                                  Я всё же утверждаю, что большая часть кода там exception-agnostic (контейнеры, алгоритмы, стримы, сишные легаси, етц). А то, что не агностик -- не нужно.

                                  От bad_alloc никуда не денешься, но там можно просто крэшится, большинство приложений не могут обработать эту ошибку.
                                  Ответить
                                  • ¯\_(ツ)_/¯
                                    А я утверждаю, что такой хуйни там навалом. А еще есть буст.
                                    Ответить
                                    • > А я утверждаю, что такой хуйни там навалом

                                      Ок, продолжай утверждать.
                                      А я и дальше буду юзать умные указатели, *map, vector, string, подмножество буста, етц.
                                      https://google.github.io/styleguide/cppguide.html#Boost
                                      Ответить
                                      • Обидно, что property tree без исключений неюзабельно: Callers of throw_exception are allowed to assume that the function never returns; therefore, if the user-defined throw_exception returns, the behavior is undefined.
                                        Ответить
                                        • > property tree

                                          Нам оно без надобности, у нас тут свои эпичные конфиги.
                                          Ответить
                                      • А я и дальше буду юзать все, что мне понадобится из стандартной библиотеки и буста. Потому что я не в гугле. По этой же причине я не буду следовать этому стайлгайду.

                                        > string
                                        http://en.cppreference.com/w/cpp/string/basic_string/at
                                        http://en.cppreference.com/w/cpp/string/basic_string/insert
                                        http://en.cppreference.com/w/cpp/string/basic_string/erase
                                        http://en.cppreference.com/w/cpp/string/basic_string/append
                                        en.cppreference.com/w/cpp/string/basic_string/replace
                                        http://en.cppreference.com/w/cpp/string/basic_string/substr
                                        http://en.cppreference.com/w/cpp/string/basic_string/copy
                                        Ответить
                                        • > Потому что я не в гугле
                                          так ты хвалишься или жалуешься?
                                          Ответить
                                          • Я объясняю тов. Кашицыну, почему я использую библиотеки, кидающие исключения.
                                            Касательно моей оценки ситуации:
                                            - Исключения - говно. Я бы хотел, чтобы в плюсах их не было.
                                            - Гугл - заебись. Это плохо, что я не работаю там CTO.
                                            Ответить
                                        • > http://en.cppreference.com/w/cpp/string/basic_string/at

                                          Все перечисленные методы кидают правильные исключения (в отличие от stol). Причина выбрасывания этих исключений -- халатность программиста. Перечисленные методы можно спокойно вызывать в любом гугловом коде, просто ошибка в коде приведёт к std::abort().

                                          > По этой же причине я не буду следовать этому стайлгайду.

                                          Можно подумать, тебя кто-то заставляет.
                                          Ответить
                                          • То-есть ты не против исключений в случае нарушения контракта, да?

                                            Исключений в том смысле, в каком они используются в Objc например, или в смысле "RuntimeException / AssertError" в жабе?

                                            Ну например сказано "не передавать сюда NULL", а его передали и получили исключение?
                                            Ответить
                                            • А между тем, в Яунде двадцать градусов тепла.
                                              Ответить
                                            • > То-есть ты не против исключений в случае нарушения контракта, да?

                                              Нет, не против. Суть в том, чтобы отличать ожидаемые ошибки от исключительных ситуаций.
                                              Проблемы с I/O при записи в файл -- ожидаемая ошибка, которую можно и нужно предусмотреть заранее и обработать.
                                              Выход за границе массива -- это ошибка в программе, которую нельзя предусмотреть и правильно обработать.
                                              OutOfMemory означает, что программист неправильно оценил ресурсы, которые требуются для корректной работы программы, с этим в большинстве случаев ничего не сделаешь.
                                              Ответить
                                              • А между тем, в Яунде двадцать градусов тепла.
                                                Ответить
                                              • Все ясно, ты о своем. Мне без разницы, по делу исключение или нет. Речь шла о том, чтобы их не было вообще. Я не хочу, чтобы эти пидоры летали по моему коду рандомно меняя поток выполнения. Если код выполз за приделы массива, то пускай падает сразу, а в остальное время я хочу видеть по коду, что творит функция.
                                                И да, я не считаю, что at() у мапы должен кидать исключение или крашить программу. Из-за такого at'а я использую find и ебу итераторы (хорошо хоть auto завезли).
                                                Ответить
                                                • >>рандомно меняя поток выполнения

                                                  а можно подробнее?
                                                  Ответить
                                                  • Ну читаешь ты чей-то код. Циклы там, ифы, функции какие-то вызываются, вроде все понятно. А хуй там плавал! Каждая строчка может быть последней, а где потом окажется выполнение - пойди проссы еще.
                                                    Ответить
                                                    • Ну если представить что ЕДИНСТВЕННАЯ реакция на Exception это "немедленно сдохнуть" то какая разница как это реализовано технически?
                                                      Сдыхает он срязу там, или наверху колстека?
                                                      Ответить
                                                • > я не считаю, что at() у мапы должен кидать исключение

                                                  Используй вместо него operator[], нет?
                                                  Ответить
                                                  • Чтобы он мне какой-то хуиты в мапу навставлял?)
                                                    Ответить
                                              • А между тем, в Яу^W^W

                                                тогда зачем городить иерархию таких исключений?

                                                И зачем механизм их отлова?

                                                -------------
                                                Воепрос тебе на засыпку: Для тупого веблога является ли недоступность СУБД ожидаемой или это исключительное?
                                                Ответить
                                                • > Для тупого веблога является ли недоступность СУБД ожидаемой или это исключительное?

                                                  Недоступность любого внешнего процесса является ожидаемой. Проектировщики апи клиента СУБД не знают, где он будет использоваться -- в веблоге или нет.
                                                  Ответить
                                                  • Ну вот из глубин ORM летит наверх SQLException.
                                                    Автор серьезного софта его ловит и обрабатывает.
                                                    Автор веблога ловит ВСЕ exceptions, пишет пользователю "temporary down", текст эксепшена (toString()) пишет в лог, и шлет письмо админу.
                                                    Админ видит текст эксепшена и все фиксит.

                                                    Все. Одинаково хендлятся ВСЕ эксепшены, буде-то место кончилось на БД или коннекшен упал.

                                                    В твоем же случае StatusOr<T> придется тащить буквально везде, до самого верху чтобы записать его в лог и сделать тоже самое.

                                                    А если метод одновременно подключается к СУБД и REST API удаленного сервиса?
                                                    Там будет уже две ошибки.

                                                    Представь как засрется API, нет?
                                                    Ответить
                                                    • > Автор веблога ловит ВСЕ exceptions, пишет пользователю "temporary down", текст эксепшена (toString()) пишет в лог, и шлет письмо админу.

                                                      Очевидно, автор этого веблога пишет на PHP и вообще живёт счастливо без всяких исключений, connect() or die(), вот это всё.
                                                      Посмотрим, как админу понравится получать письмо каждый раз, когда KeyError какой-нибудь случится.
                                                      Ответить
                                                      • А между тем, в Яунде двадцать градусов тепла.
                                                        Ответить
                                                      • Ну а если он пишет на java?

                                                        KeyError это одноразовая ошибка, а no space left on device явно волнует админа, разве нет?
                                                        Ответить
                                                  • Другой пример: у меня есть интерфейс за которым стоит удаленный сервис.
                                                    Ремоутинг, значит.

                                                    Ты правда будешь пихать в КАЖДЫЙ (даже войд, лол!) метод status?
                                                    Ответить
                                                    • В го так и делают. А в типичном расте вообще половину кода .unwrap() занимают.
                                                      Ответить
                                                      • Разве не говно?

                                                        А с другой стороны проблема напоминает nullify.
                                                        В современных ЯП принято иметь для Nullable и notnull разные типы, и заставлять юзера явно проверять что значение не null.

                                                        Kotlin e.g.

                                                        Тут почти тоже самое
                                                        Ответить
                                                        • Мне в го нормально было. В плюсах с optional тоже было бы ок.
                                                          Ответить
                                                    • > Ты правда будешь пихать в КАЖДЫЙ (даже войд, лол!) метод status?

                                                      А в чём, собственно, проблема? Идея относится к удалённому сервису так, будто он ничем не отличается от локального -- уже плохая. Даже жабисты это поняли на заре RMI, поэтому чекед RemoteException кидается из каждого прокси.
                                                      Ответить
                                                      • RMI давно проклят и забыт. Спринг так не делает, например.
                                                        Другой пример это прокси-классы на SOAP.

                                                        >>Не отличается от локального -- уже плохая
                                                        Во ты сейчас просто взял, и насрал на целый пласт архитектуры, понимаешь?

                                                        А если у меня есть алогритм который должен быть агностик на тему того локальный он или удаленный?

                                                        Конечно, удаленный будет работать в 38 раз медленее, но и пофиг. Это ентерпрайз, он асинхронно обрабатывает заказ, и мне не важно что он занимает не 15 секунд а 15 минут.
                                                        Почему я должен его менять?
                                                        Ответить
                                                        • > агностик на тему того локальный он или удаленный
                                                          Ну вот и пусть всегда считает, что он удалённый, даже если исполняется локально ;)
                                                          Ответить
                  • Я сочиняю роман
                    Кашицын всей моей жизни
                    Иду по вечному кругу
                    Ответить
                    • >>Иду по вечному кругу
                      Ебут тебя во все дыры, да? )
                      Ответить
              • PS: >>Как в языке выразить мысль, что метод кидает то же самое исключение, что кидает его функция-параметр? Никак.

                Вот это кстати хуйня полная. Это же элементарно было бы сделать. Так почему не сделали?

                Пусть функция, чей формальный параметр есть другая функция с эксепшеном E явно говорит (ну или при вызове ее явно указывается): "я прокину E" либо "я обязуюсь поймать и обработать E".

                А знаешь почему эта, казалось бы элементарная, мысль не пришла никому в голову?
                Потому что никто не умеет checked exceptions, даже в Oracle:) Все думают что это "говно какое-то и всё равно его никто не юзаеот"
                Ответить

    Добавить комментарий