// clean up here, e.g. save the session
// and close all config files.

Не, не видел. Лыблюсь так, что глаза слипаются.

Чисти, сохраняй сессий, закрывай конфиги, делай что хочешь, а итог один - return 0; // exit the application :-) Ч.т.д. :-)

Чисти, сохраняй сессий, закрывай конфиги, делай что хочешь, а итог один - return 0;

А теперь попробуйте объяснить, как проделать все это, если вместо выбрасывания bad_alloc-а вы разыменовали нулевой указатель.

Сможете?

Смогу :-) Тоже, что любой вменяемый сделает в случае отказа электроснабжения - восстановлю битый конфиг из копии при следующем запуске и начну сессию с последнего чек-поинта :-) Такие дела :-)

Или в цепепе даже можно отловить исключение, выпавшее из электророзетки, и даже тут восстановиться? :-) Лол :-)

Макры – невероятная годнота. При грамотном применении дают чудовищную экономию сил.

Поэтому я и просил технические аргументы против подобного подхода.

«Это неудобно», ну и легко игнорировать (свести к обычным исключениям).

Что характерно - в тех языках, где от исключений «отказались», они всё равно, в том или ином виде, присутствуют.

Звучит воистину ужасно.

Так только кажется.

Макры – невероятная годнота. При грамотном применении дают чудовищную экономию сил.

По-больше бы таких :-)

Побольше хороших макр? Я только за.

Что характерно - в тех языках, где от исключений «отказались», они всё равно, в том или ином виде, присутствуют.

Например?

Побольше хороших макр? Я только за.

По-больше желающих ими пользоваться :-)

Но это всё не является поводом не стремиться к лучшему, правда?

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

Например Go. panic/defer практически в чистом виде throw/catch.

panic/defer локален к функции. Эксцепшоны - нет.

Например?

Например, Go. Несмотря на все разговоры про «errors are values», всё равно присутствуют defer/panic/recover. Хотя даже в FAQ есть пункт про то, что в языке «нет исключений».

Или Rust - паника, опять же, присутствует. При этом обрабатывать её ещё менее удобно, чем в Go. Вероятно, это «подталкивает» разработчиков использовать явные возвраты ошибок через Option/Result, но мы ведь говорим о гарантиях.

В уже упомянутой скале есть и Either/Option и исключения.

В Swift ещё забавнее. В обжектив-С ведь исключений толком не было, так что свифт продолжает использовать возврат ошибок. Вот только там применяется сахар и реальных типов возможных исключений просто не видно. В сигнатуре функции будет только «throws».

panic/defer локален к функции.

Это что значит?

Или Rust - паника, опять же, присутствует. При этом обрабатывать её ещё менее удобно, чем в Go. Вероятно, это «подталкивает» разработчиков использовать явные возвраты ошибок через Option/Result, но мы ведь говорим о гарантиях.

panic в Rust и error в Haskell предназначены сигнализации об ошибках в коде, и обрабатывать их не следует вообще.

Это значит, что тебе не прилетит из функции, которую ты вызываешь.

http://blog.golang.org/defer-panic-and-recover

When the function F calls panic, execution of F stops, any deferred functions in F are executed normally, and then F returns to its caller. To the caller, F then behaves like a call to panic

panic в Rust и error в Haskell предназначены сигнализации об ошибках в коде, и обрабатывать их не следует вообще.

Мы всё ещё говорим о гарантиях или «рекомендациях»?

Это значит, что тебе не прилетит из функции, которую ты вызываешь.

Да ну?

А... Вот блять :D

Мы всё ещё говорим о гарантиях или «рекомендациях»?

Да, ты прав.

Имхо, достаточно даже факта того, что в самой Java есть RuntimeException, если не ошибаюсь, которое может выскочить несмотря на все checked exceptions. И, следовательно, код на Java нужно писать оглядываясь на то, что из некого метода f() может выскочить не только те исключения, которое перечислены у него в throws.

Все верно, но ведь вам никто не мешает перехватить и RuntimeException, если уж так хочется, только вот это будет дурным тоном.
Да тот же OutOfMemoryError при нехватке памяти можно поймать, и, если сильно приспичит, изменить алгоритм работы для восстановления (урезание выделения памяти, допустим).
Но, повторюсь, лично для меня перехватывать RuntimeException и иже с ними - признак дурного тона, ибо это показатель некомпетентности разработчика, пытающегося «заглушить» последствия, вместо того, чтобы найти и устранить причину непосредственно в самом коде, т.к. ошибка выполнения по определению - показатель кривого кода в 99% случаев (1%, так и быть, отдам экстраординарным ситуациям).

Все верно, но ведь вам никто не мешает перехватить и RuntimeException, если уж так хочется

Речь не о том, что нельзя перехватывать RuntimeException. А о том, что список задекларированных в throws исключений отнюдь не исчерпывает список тех исключений, которые могут выскочить. Т.е. если где-то кто-то написал что-то вроде:

class Service {
  public void doSomething() throws FileNotFoundException {...}
  ...
}

class Client {
  public void useService(Service svc) {
    try {
      SomeResource res = allocateSomeResource();
      svc.doSomething();
      res.close();
    }
    catch(FileNotFoundException ex) {
      handleProblem(ex);
      res.close();
    }
  }
  ...
}

Я вас понял, но ведь я об этом и сказал

ошибка выполнения по определению - показатель кривого кода в 99% случаев

Поэтому проблема в самом коде

А о том, что список задекларированных в throws исключений отнюдь не исчерпывает список тех исключений, которые могут выскочить.

Верно, их может быть сколько угодно, хоть 100500 возможных вариантов, но это ничего не меняет. Если вы знаете, что в данном, конкретном участке кода, есть потенциальная возможность поймать 6 различных типов исключений времени выполнения, то пишите код, пытаясь максимально избегать их, а не думайте о том, какое бы вам еще исключение поймать.
Тот же банальный пример с OutOfMemoryError. Допустим, имеем задачу с решетом Эратосфена до 1 млрд. Вместо того, чтобы выкручиваться наизнанку, пытаясь заставить Java выделить массив целых чисел до 1ккк и, одновременно с этим тупо обернуть это в try catch (OutOfMemoryError e) - нормальный разработчик должен спроектировать решение задачи на n-ное кол-во шард, основываясь на средних возможных ресурсах машин целевой аудитории программы.

Но, повторюсь, лично для меня перехватывать RuntimeException и иже с ними - признак дурного тона, ибо это показатель некомпетентности разработчика, пытающегося «заглушить» последствия, вместо того, чтобы найти и устранить причину непосредственно в самом коде

Давно хочу спросить - говоришь ты много, гладко и правильно, а сам-то реальный код пишешь? Или Java couach?

думайте о том, какое бы вам еще исключение поймать

Вот никогда этого не понимал. Зачем нужно думать о том, какие исключения ловить?

Сейчас проектирую систему сквозной бизнес-аналитики (типа Roistat), где как раз нужен добротный анализ целевой аудитории. Я работаю в коммерц. сфере, поэтому извини, но никакого кода я тебе не запилю сюда.

Давно хочу спросить - говоришь ты много, гладко и правильно, а сам-то реальный код пишешь

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

Я начинал работать в далеком 2010 в Екатеринбурге, в задохлых web-конторах, таких как Menocom. Проработав всего два года начальником отдела разработки, я повстречал довольно много разработчиков (конечно, в основном это PHP головного мозга, но есть и Питонисты), которые просто помешаны на концепции кинь исключение - поймай исключение. Да, это по большей своей части студенты, но некоторые из них писали специально так, чтобы придумывать кучи своих ненужных иерархий исключений. Не знаю, может кому-то это по приколу было. Я лично этого так же не понимаю.

извини, но никакого кода я тебе не запилю сюда

Я хотел знать только, пишешь ли ты его.

В большинстве своем проектирую

Я начинал работать в далеком 2010

Ясно, спасибо.

Я начинал работать в далеком 2010 в Екатеринбурге, в задохлых web-конторах, таких как Menocom. Проработав всего два года начальником отдела разработки

Вот эта информация к чему была? Типа достали и предъявили?

Ну уж извиняйте, мне всего 23 года, начал работать с 18 лет, сразу как покинул родные края, а «баловаться программированием» начал с 13-ти.
Да, для вас конечно такие цифры явно не показатель, у вас то ведь опыт по 20-30 лет у всех, но знаете, мне хватает, я не жалуюсь. Выше своей головы я прыгать не стараюсь, по крайней мере.

Off-topic

Эта информация была на стандартную тему

говорить мы все мастаки, а на деле кто ты такой?

К тому, что если будете в здешних краях Урала, можем накатить по паре пивка :)
Если что-то не нравится, извиняйте, ухожу их темы. Я ЛОР читаю давно, уже уяснил что с «бывалыми» лучше не препираться. Поэтому я пойду, оке?

Потому что ортогонально как ООП, так и теме разговора. Взяли м сделали

говорить мы все мастаки, а на деле кто ты такой?

В Интернетах выяснять это практически не имеет смысла.

Но речь о другом. Вот вы написали:

то пишите код, пытаясь максимально избегать их, а не думайте о том, какое бы вам еще исключение поймать

Я не понял, о чем вы ведете речь. Думал, что вы объясните. Вместо этого вы стали перечислять свой опыт. Это, к сожалению, не является пояснением вашей точки зрения.

Я не понял, о чем вы ведете речь.

А я разве не объяснил? Я дал элементарный пример задачи

алгоритм нахождения всех простых чисел от 2 до N.

В котором показал что можно

писать код, пытаясь максимально избегать исключений

В ситуации, когда

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

Вместо

пытаясь заставить Java выделить массив целых чисел до 1ккк и, одновременно с этим тупо обернуть это в try catch (OutOfMemoryError e)

Когда программист

думает о том, какое бы вам еще исключение поймать (OutOfMemoryError)

Если для вас это

не является пояснением вашей точки зрения

то вы можете сказать мне что конкретно вы не поняли из моего объяснения.

А я разве не объяснил?

Нет. Ну или я не понял. Как раз таки размещение в памяти очень большого массива имеет смысл обернуть в try-catch и поймать OutOfMemoryError дабы преобразовать его в более вменяемое прикладное исключение, скажем, NotEnoughResourcesException.

Так что пример уже неудачный. А когда он дополняется фразами: «спроектировать решение задачи на n-ное кол-во шард, основываясь на средних возможных ресурсах машин целевой аудитории программы» то складывается ощущение, что я богатый клиент, которому ушлый продавец хочет впарить что-то ненужное под завесой красивых фраз из умных слов.

Так что пример уже неудачный.

Хорошо, возьмем другой пример. Берем IllegalArgumentException. И, допустим, у нас есть 2 ситуации:

1. Неинициализированный объект.
2. Выход за пределы массива.

Так вот, моя точка зрения «не ловить все что попадя» заключается в том, что первую ситуацию (неинициализированный объект) следует обрабатывать, т.к. ваше приложение может быть сервисом, которым пользуется не гик, а среднестатистический разработчик. Именно поэтому, мне в параметр метода могут передать null вместо объекта, и я должен буду обработать такую ситуацию (тем же IllegalArgumentException, допустим)

public SomeObjectOne SomeMethod(SomeObjectTwo obj) {
    if (rect == null) { 
        throw new IllegalArgumentException("bla-bla-bla");
    }
    // ...
}

то пишите код, пытаясь максимально избегать их, а не думайте о том, какое бы вам еще исключение поймать

или нужны еще примеры?

или нужны еще примеры?

Не, стало понятно, почему tailgunner спрашивал, пишете ли вы код.

И о чем это говорит? Я ведь сказал что пишу :)

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

Это значит что 20% рабочего времени я его все же пишу.
Вы бы по факту сказали что не так, а не напускали на себя туманщины.

Вы бы по факту сказали что не так, а не напускали на себя туманщины.

Не так то, что вы говорите правильные слова, но из ваших объяснений мало что понятно. Такое встречается у опытных архитекторов.

Off-topic Вы просили объяснений чтобы затроллить?
Слишком толсто. Сливаюсь из темы, пусть здесь рулят гуру кода. Царя на вас не хватает.

Как раз таки размещение в памяти очень большого массива имеет смысл обернуть в try-catch и поймать OutOfMemoryError дабы преобразовать его в более вменяемое прикладное исключение, скажем, NotEnoughResourcesException.

Я думаю, имеется в виду «если надо уметь обрабатывать данные, которые могут не поместиться в память одного узла, нужно делать шарды, которые гарантированно поместятся в память, а не определять объем доступной памяти динамически».

Царя на вас не хватает.

Ну, царь считает анскильными лалками нас всех, без исключений.

Вы просили объяснений чтобы затроллить?

Нет. Ваш последний пример был более-менее понятен, но своими объяснениями вы его только усложнили. Как по мне, все гораздо проще: если дергая SomeMethod вы знаете, что делать с IllegalArgumentException, то вы это исключение перехватываете. Если не знаете, не перехватываете. Все ваши выделенные жирным зоны риска здесь не при чем.

Ну, царь считает анскильными лалками нас всех, без исключений.

Ну а теперь вы, скорее всего, будете считать меня анскилом только потому что я мало «пишу кода». И какая ж тут разница?
Посему уж лучше царь, я хоть на фоне вас буду таким же среднестатистическим неосилятором, всяко приятнее будет :)

Вот за это спасибо. Действительно конструктивное замечание, в следующий раз попытаюсь осилить KISS в плане объяснений и примеров :)

В каком из языков лучшая реализации ООП?

в Common Lisp. а эти оба сосут.

man Fragile Base Class problem, «синтаксическая и семантическая хрупкость базового класса» (с) Клеменс Шипёрски, «компонентно-ориентированное программирование», «stable API considered harmful» (c) Линус Троллололльвальдс

ещё в SML/NJ неплохая — с модулями в виде структур, сигнатур и функторов, и функциональными объектами поверх таких вот модулей.

Ну а теперь вы, скорее всего, будете считать меня анскилом

Чтобы я считал кого-то анскильной лалкой, этот кто-то должен сильно постараться. А пока я просто считаю, что ты склонен выражаться слишком цветисто для прогера.