Нашли или выдавили из себя код, который нельзя назвать нормальным,
на который без улыбки не взглянешь?
Не торопитесь его удалять или рефакторить, — запостите его на
говнокод.ру, посмеёмся вместе!
AccessibleComponent - интерфейс, ничего общего не имеющий с Component, зато являющийся частью расширения javax Accessibility. Они и не должны быть в одной ветке = )
А Вы не находите, что проблемы тут в проектировании?
вот еще пример - InputStream и OutputStream implements Closeable
А java.sql.Connection, java.sql.Statement и java.sql.ResultSet не реализуют этого интерфейса. Говорят в 7-ой жабе это пофиксили, но сколько ж лет оно так криво было.
Нахожу, собственно, поэтому задал вопрос выше.
Дурно пахнущий код, который ещё и непонятно как рефакторить - явный признак ошибки на уровне архитектуры.
Ну в примере с Closeable - у меня сделано именно через рефлексию.
Тут это слишком накладно м наверняка им стоило завести какой-то общий интерфейс.
A <em>Component</em> is an object having a graphical representation
* that can be displayed on the screen and that can interact with the
* user. Examples of components are the buttons, checkboxes, and scrollbars
* of a typical graphical user interface. <p>
* The <code>Component</code> class is the abstract superclass of
* the nonmenu-related Abstract Window Toolkit components. Class
* <code>Component</code> can also be extended directly to create a
* lightweight component. A lightweight component is a component that is
* not associated with a native opaque window.
The AccessibleComponent interface should be supported by any object
* that is rendered on the screen. This interface provides the standard
* mechanism for an assistive technology to determine and set the
* graphical representation of an object.
>>> A Component is an object having a graphical representation that can be displayed on the screen
>>> The AccessibleComponent interface should be supported by any object that is rendered on the screen.
>>>should be supported by any object that is rendered on the screen.
>>>any object that is rendered on the screen
Загадка. Я с accessibility не работал, не знаю всей глубины замысла. Вероятно, были серьёзные идеологические причины или это просто невозможно. Ведь если это ошибка, то исправить её можно было бы в любой момент.
Кстати, именно для решения таких косяков в Scala есть Structural Subtyping: входными параметрами функций могут быть любые типы, содержащие определённые методы, к примеру close:
я потихоньку стараюсь осваивать, правда, к сожалению, на работе пригодиться в обозримом будущем.
Почти дочитал Programming in Scala, пока в восторге. Реально сокращает число букв, которые нужно набирать. Плюс есть полная обратная совместимость с Java. Единственный ощутимый косяк - нет пока нормальной IDE (язык настолько мощный, что я понимаю, почему её сложно сделать). Говорят, для IntelliJ IDEA есть нормальный плагин, но я его пока не пробовал. Поскольку пишу пока только игрушечный код, мне вполне хватает emacs + scala interpreter + maven.
Собственно, выше ответ. Лучше всего поставить IntelliJ IDEA CE 10.5.2, потом лезем в Settings-> Plugins->Available, выбираем Scala и жмакаем Download and Install.
Имхо по уму checked exceptions максимум должны просто выдавать ворнинг "исключение не поймано", с отлючением вообще функции через свитч компилятора при прототипировании -- и всё. Было бы весьма полезно.
А зачем, какая причина порождать java.sql.Statement от Closeable? То, что название метода совпадает — просто случайность. Вот в семёрке причина появилась — и вели AutoCloseable.
>То, что название метода совпадает — просто случайность.
Никак нет, сер. Там очень много классов с методом close.
RMIConnection, например.
public void close() throws IOException; а интерфейс не имплементит
>А зачем?
Обычно пресловутый Exception игнорится и если хочется чего-то закрыть нужно писать
try{
close(something);
}catch(){}
А если нужно закрыть PreparedStatement, а за ним Connection, или 2 Connection подряд приходится новое закрытие снова оборачивать в try-catch. По понятным причинам.
А если оно все имплементит Closable делаем метод
static void close(Closable cl){
try{cl.close}catch(Exception e){};
}
или даже так
static void close(Closable... cl){
Массивы появились до генериков (где ковариантность/контровариантность можно выразить через wildcards), и кажется варианта было тут только два:
1. Сделать их инвариантными, и заставить программиста вручную кастить каждую овцу к Mammal, что в отсутствии функциональных средств попродило бы кучу бойлерплейта, да еще и ударило бы по производительности
2. Сделать их ковариантными, и проверять в рантайме.
И какой процент случаев, когда они НЕ игнорируются?
Да и вообще речь о том, что если уж вводить новый интерфейс с методом
>close is invoked to release resources that the object is holding.
то стоит сделать его универсальным.
По-настоящему надёжный код не должен просто игнорировать исключение. Да, разумнее было бы в этом случае не исключение бросать, а код ошибки возвращать, но так уж… Не Javish.
Кстати, Closeable ведь только с 1.5. Вот и ответ на вопрос.
>По-настоящему надёжный код не должен просто игнорировать исключение
Да в большинстве случаев этот "надёжный код" просто выводит сообщение и закрывает программу. В принципе абсолютно то же самое происходит при стандартное поведении системы при непойманном исключении, только вот весёлый Гослинг заставляет нас писать больше букав просто так.
Если уж и заботиться о суперкритичном софте (типа софта для бирж), то можно было бы сделать свитч компилятора XX:+critical, который бы не компилировал код при непойманных исключениях, и XX:-critical, который бы просто выводил ворнинг. Выбирай нужный свитч под тип приложения.
это явный косяк. В Spring, к примеру, вообще днём с огнём не встретишь checked исключений. Если у тебя ошибка закрытия файла (в жизни такого не видел), что ты можешь сделать как программист? Unchecked исключения можно ловить там, где это имеет смысл, а таскать checked исключения в сигнатурах методов через весь код очень неудобно.
для чего вообще были придуманы checked exceptions? чиста ради того, чтобы на раннем этапе можно было знать, чего ждать от метода и не забыть отловить все что вылетает
>и не забыть отловить все что вылетает
Как я уже сказал, можно было просто выводить ворнинг, а не вообще отказываться компилировать. Хорошие программисты обратят внимание на ворнинг, а плохие будут делать путые try...catch...finally в любом случае и при checked exceptions, ровно как и игнорировать ворнинги. Так что толка нет никакого.
Создателя успешных на Западе видеоигр обвинили в насилии
Его жена рассказала, что он похитил ребенка и избил ее отца, а бывшие студенты говорят, что он совращал несовершеннолетних
Я (фронтендер) в начале пути просто обожал миксины (подвид множественного наследования). Пихал их по поводу и без везде, было удобно и понятно, код переиспользуется, все классно
вот еще пример - InputStream и OutputStream implements Closeable
А java.sql.Connection, java.sql.Statement и java.sql.ResultSet не реализуют этого интерфейса.
Говорят в 7-ой жабе это пофиксили, но сколько ж лет оно так криво было.
Дурно пахнущий код, который ещё и непонятно как рефакторить - явный признак ошибки на уровне архитектуры.
Тут это слишком накладно м наверняка им стоило завести какой-то общий интерфейс.
>>> A Component is an object having a graphical representation that can be displayed on the screen
>>> The AccessibleComponent interface should be supported by any object that is rendered on the screen.
>>>should be supported by any object that is rendered on the screen.
>>>any object that is rendered on the screen
Потому что тут явно у кого-то проблемы с логикой.
Кстати схожие ощущения.
И по скорости исполнения тоже неплохо так смотрится. В отличии от Groovy.
Почти дочитал Programming in Scala, пока в восторге. Реально сокращает число букв, которые нужно набирать. Плюс есть полная обратная совместимость с Java. Единственный ощутимый косяк - нет пока нормальной IDE (язык настолько мощный, что я понимаю, почему её сложно сделать). Говорят, для IntelliJ IDEA есть нормальный плагин, но я его пока не пробовал. Поскольку пишу пока только игрушечный код, мне вполне хватает emacs + scala interpreter + maven.
http://stackoverflow.com/questions/419207/which-is-the-best-ide-for-scala-development
Никак нет, сер. Там очень много классов с методом close.
RMIConnection, например.
public void close() throws IOException; а интерфейс не имплементит
>А зачем?
Обычно пресловутый Exception игнорится и если хочется чего-то закрыть нужно писать
try{
close(something);
}catch(){}
А если нужно закрыть PreparedStatement, а за ним Connection, или 2 Connection подряд приходится новое закрытие снова оборачивать в try-catch. По понятным причинам.
А если оно все имплементит Closable делаем метод
static void close(Closable cl){
try{cl.close}catch(Exception e){};
}
или даже так
static void close(Closable... cl){
1. Сделать их инвариантными, и заставить программиста вручную кастить каждую овцу к Mammal, что в отсутствии функциональных средств попродило бы кучу бойлерплейта, да еще и ударило бы по производительности
2. Сделать их ковариантными, и проверять в рантайме.
что они и сделали
Да и вообще речь о том, что если уж вводить новый интерфейс с методом
>close is invoked to release resources that the object is holding.
то стоит сделать его универсальным.
Кстати, Closeable ведь только с 1.5. Вот и ответ на вопрос.
Да в большинстве случаев этот "надёжный код" просто выводит сообщение и закрывает программу. В принципе абсолютно то же самое происходит при стандартное поведении системы при непойманном исключении, только вот весёлый Гослинг заставляет нас писать больше букав просто так.
Если уж и заботиться о суперкритичном софте (типа софта для бирж), то можно было бы сделать свитч компилятора XX:+critical, который бы не компилировал код при непойманных исключениях, и XX:-critical, который бы просто выводил ворнинг. Выбирай нужный свитч под тип приложения.
кстати, Ховард негодует тоже:
даже если он не знает, какие именно
Как я уже сказал, можно было просто выводить ворнинг, а не вообще отказываться компилировать. Хорошие программисты обратят внимание на ворнинг, а плохие будут делать путые try...catch...finally в любом случае и при checked exceptions, ровно как и игнорировать ворнинги. Так что толка нет никакого.
Создателя успешных на Западе видеоигр обвинили в насилии
Его жена рассказала, что он похитил ребенка и избил ее отца, а бывшие студенты говорят, что он совращал несовершеннолетних
Я (фронтендер) в начале пути просто обожал миксины (подвид множественного наследования). Пихал их по поводу и без везде, было удобно и понятно, код переиспользуется, все классно