DarkSquid softwarer
Softwarer, вы чепуху пишете. Поймите, что если я знаю, что эксепшин произошёл именно здесь, я смогу посмотреть и остальные куски программы, узнать какого класса была переменная textField и была ли она проинициализирована.
Какого класса переменная textField, вообще-то ясно из ее названия. Вы, конечно, можете потратить неопределенное количество времени, прослеживая, будет ли инициализирована эта переменная во всех возможных вариантах выполнения программы. Например, мой любимый код:


Как, будет textField инициализирована или не будет? Что ж, допустим Вы проследили все ветки и даже нашли правильный ответ. И что из этого? Проблема-то на самом деле в том, что getText() возвращает null. И нахрена было заниматься подобным прослеживанием?

jdev333Ага. Как же не думаете, когда вменяете смысл о влиянии javaDoc на java? Не свидетельствовала "та" wessen-а фраза об этом. Никак.
Вы, безусловно, можете иметь по этому поводу любое собственное мнение. Там было сделано обоснование от противного - throws нужны, поскольку иначе, читая javadoc, было бы трудно/невозможно получить некоторую информацию. Со схемой доказательства от противного, надеюсь, знакомы? Она формулируется так: (a => b) => (!b => !a), где a и b - некоторые утверждения. В данном случае a = "throws не нужны", b = "[как бы Вы иначе,] читая javadoc..."

jdev333При использовании явы должно было появиться ощущение неприятия проприетарности в др платформах, ибо платформа java развивается на открытых стандартах.
Хм. Лично для меня это набор малоосмысленных слов; мне интереснее качество. Впрочем, хочется спросить - и давно оно должно было появиться? Если мне не изменяет память, по вопросу открытости жабы уже сломано и продолжает ломаться очень много копий; можно в конце концов вспомнить тот судебный процесс между саном и микрософтом, итогом которого стал .NET.

wessen
if(child == null)
throw new NullPointerException("Null child not allowed");
if (model == null) {
throw new IllegalArgumentException("model must be non null");

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

DarkSquidДа что Вы мне сказки рассказываете? Я превосходно знаю, как поддержка программ на Дельфи осуществляется.
И при этом задаете вопросы, ответы на которые знают даже новички дельфовых форумов (про OnException). Так что простите, но к любому Вашему утверждению о знании дельфы, я теперь отношусь с очень большой долей скепсиса.

DarkSquidТам пробел в редакторе отчётов в запросе лишний поставишь - и эксепшин вылетает.
А там есть редактор отчетов? :) И какой именно?

DarkSquidИ никто это годами не фиксит.
Хм. Ну если ваши программисты так сопровождают известные ошибки.. Или это вам продали какую-то программу, которую так сопровождали?

DarkSquidА что такое VCS я не знаю,
http://www.google.ru/search?hl=ru&ie=windows-1251&q=acronym+VCS&lr=

DarkSquidи как мне MemCheck использовать для инвестигации той ошибки, которая уже произошла у кастомера, ума не приложу.
Интересно, где наш внимательный собеседник, следящий за передергиваниями.

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

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

DarkSquidИ кастомеру что не интересно знать, так это не стектрейс, кторый поможит быстрее пофиксить ошибку, а вот именно сообщение о том, что программа не может прочесть адрес в памяти не интересно кастомеру знать. И программисту оно ничего не скажет.
Хм. Вы наворотили какой-то страшный набор слов; если я правильно понял:

1. Клиенту неинтересно знать, что произошла ошибка. То, что исключение молча упало в трейс, его вполне устраивает. Ну не прореагировала никак программа на действия пользователя - и фиг с ней, нажмет OK еще раз двадцать, и если так и не прореагирует - пойдет обедать.

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

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

DarkSquidСкажем - какой контекст Вам нужен для ответа на тот мой пример, на который Вы так и не ответили?
Ну не собираюсь я на это отвечать. Детский сад какой-то. Это ж очевидно и потому только на собеседовании уместно.
То есть для тривиального детсадовского примера из одной строки Вы не можете либо не хотите дать столь же однострочный ответ, который, судя по Вашей теории, существует. OK.

Кстати, не знаю как Вы, а я на собеседованиях предпочитаю давать не детсадовские примеры - мне нужны недетсадовские люди.

DarkSquidЕсли есть стек трейс - так бы и сказали бы, что есть,
Дык сказал, раз десять.

Ewg_довод выбравших жаву - мол на клиенте ничего ставить не надо, развертывание приложений и новых версий = 0 ресурсов
Это не совсем так. Если говорить о веб-приложении, развертывание разумеется ноль, но тут ключевым словом является "веб", а уж на чем он - вопрос второй. Если говорить об апплетах и гуевых приложениях, не все так просто; в принципе технологии для развертывания есть, но отсутствие проблем никто не гарантирует. В целом я не вижу большой разницы, то ли клику запустится какой-нибудь Java Web Start, то ли по клику запустится setup.exe. Для тридцати тысяч пользователей в случае дельфы стоило бы подыскать хорошее решение, но для тридцати единиц - вообще не о чем говорить. Стоимость самого тупого варианта - "идет администратор с флэшкой" - составит максимум баксов двести; на фоне стоимости разработки - не аргумент.

Ewg_у дельфи есть 3-ка.
кстати где почитать о ее плюсах ?
только имеет ли она смысл при 30 пользователях?
Количество пользователей само по себе не слишком влияет на смысл трехзвенки - только в той степени, что при таких масштабах обычно и приложение невелико, а значит его усложнение менее нужно.

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

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

DarkSquidТам весь интерфейс блокируется, на самом деле. Чтобы не блокировалось надо в отдельной треде ручками пускать.
Это подразумевается, поскольку если этого не делать, блокируется слишком уж хорошо - не идет, например, перерисовка progressbar-ов итп. Кроме того, я натыкался на блокировку, возникавшую из-за того, что стандартный листенер пытался дождаться освобождения event thread.

DarkSquidВон у Softwarer'а, как я понял, притензии к конкретным IDE и тулкиту, которые он использует.
Хм. А можно с этого момента поподробнее? Тулкит, к которому я высказывал претензии, назывался Swing (ну или JDK, если угодно). Если есть альтернативы JDK, я буду очень признателен за ссылки.

DarkSquidThread.setDefaultUncaughtExceptionHandler(new MyUncaightExceptionHandler());
Вот за эту подсказку - спасибо. Пока мы пользуемся четверкой, но будет еще один аргумент в пользу пятерки.

Сказанное же Вами в следующем сообщении, к сожалению, чуть менее полезно - может быть я ошибаюсь, но я не увидел способа применить эту технику к event thread-у, который AWT создает внутри себя. В собственных же потоках, понятно, эта проблема легко решается в любом случае.

DarkSquidgetText() null не возвращает.
Да, здесь я ошибся. Возможно, это наследие JDK 1.3 - проект начинался на нем, и соответствующая доработка в нашем коде появилась именно тогда. У меня сейчас нет его на машине, чтобы посмотреть.

DarkSquidА есть ли в Delphi стандартные классы для быстрого поиска по ключу и работы с множествами объектов?
Есть реализация STL для дельфы.

wessenну так вы же этот пример надумали. кто вам мешает использовать два раза NullPointerException?
Этот пример, простите, не я надумал, а авторы JDK, и вопрос стоило бы адресовать им. Относится этот пример к образцовой логичности. Если уж сами авторы не совсем понимают, что когда использовать в ими же созданном продукте, имхо это наводит на некоторые размышления.

wessenи вообще, мы спорили о throws. И логичным я назвал то, что NullPointerException и IllegalArgumentException не нужно объявлять как throws.
Давайте тогда отмотаем чуть назад. Вы назвали throws логичным, поскольку она дает информацию о возможных исключениях. Хорошо. С моей точки зрения, например, абсолютно логичен вызов setModel (null). Почему-то этот логичный вызов вызывает exception, причем не NullPointerException, которого я мог бы ожидать по предыдущему опыту с JTree, но нечто другое. Информации об этом - нет, по крайней мере в throws. Мне все равно надо лезть в исходники и проверять.

Да, такая ошибка может быть выявлена и устранена на этапе тестирования. Ровно так же, как и любая другая ошибка. Следовательно, либо вообще не реагируем на ошибки, либо - это не аргумент.

Ладно, предположим в рамках этого рассуждения, что я неправ, уже здесь начиная считать throws... малополезным. Можно было бы считать так: физические ошибки, типа (String s = null).length() хорошие программисты не делают, поэтому не ловим; ловим исключения, которые явно возбуждаются. Но - не ловим, оказывается; вот возбуждается исключение, оно логическое (дурацкая недоработка класса JList), а никакого throws нет, и это считается логичным. Что дальше?

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


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


Нет, если честно, не кажется мне все это продуманной, стройной и удобной системой.

2 note... Судя по Вашей попытке, беседовать с Вами будет совершенно скучно. Извините, избегну.