То, почему Java не был, “бросает” пункт (в объявление метода) включенный в C#?
Вы можете использовать mouseup, mousedown и mousemove события для достижения этого:
var isDragging = false;
$("#clickshow")
.mousedown(function() {
isDragging = false;
})
.mousemove(function() {
isDragging = true;
})
.mouseup(function() {
var wasDragging = isDragging;
isDragging = false;
if (!wasDragging) {
$("#information").toggle();
$("#clicktoshow").toggle();
}
});
5 ответов
Anders Hejlsberg (ведущий архитектор C#) объясняет его в этом интервью:
(В дополнение к несколько категорическому ответу Patrik.)
Контролируемые исключительные ситуации в Java являются очень спорным вопросом. Я раньше любил их и пропустил их много при записи C#. Было такое чувство, что я был ведущим без ремня безопасности. Теперь, они раздражают меня..., потому что, в то время как они походят на хорошую идею в теории, они имеют определенно , вызвал меня много горя, но не предоставляя много материального преимущества. Я не могу помнить никогда обнаружение с ошибкой в коде C#, от которого контролируемые исключительные ситуации сохранили бы меня. Но это вовсе не значит этого не может произойти, но этого не произошло со мной.
раздражающая вещь состоит в том, что до некоторой степени все еще такое чувство, что C# слишком слаб - но что подход Java не является вполне правильным. Это похоже существует лучшее решение, ожидающее, чтобы быть обнаруженным, и попытка Java была хорошим экспериментом, но это не вполне работало.
Главная причина состоит в том, что разработчики C# решили не использовать "контролируемые исключительные ситуации". Это означает, что разработчик не должен окружать исключение, бросающее пункт в блоке try-catch. Считалось, что это только полезно для мелкомасштабных приложений и не обладает реальным преимуществом для больших проектов. Дополнительно контролируемые исключительные ситуации на самом деле неправильно использовались разработчиками, которые постоянно используют пустые блоки выгоды. С тех пор нет никаких контролируемых исключительных ситуаций, нет никакой причины метода для объявления, какие исключения могли быть выданы.
использование или не "контролируемых исключительных ситуаций" является спорной темой, но большинство, кажется, соглашается, что нет никакой потребности в них. Spring, который является видной платформой в Java, превращает контролируемые исключительные ситуации в во время выполнения.
Я думаю, что контролируемые исключительные ситуации, как функция языка, представляют некоторые культурные различия между Microsoft и Sun.
По большей части, Microsoft является клиентской компанией. Большая часть программного обеспечения, которое они делают, и для чего предназначена их стопка разработки, является клиентским программным обеспечением.
Да, да, я знаю, что Microsoft делает программное обеспечение сервера. Однако Office и Windows является ПУТЬ, больше с точки зрения дохода, чем Windows Server и Exchange.
я думаю, что справедливости ради стоит отметить, что большая часть программного обеспечения, записанного в.NET, (и еще больше с VB 6), является клиентским программным обеспечением. Несомненно, большим блоком его является Web Software, которая работает на веб-сервере, но большая часть из него действительно... "clienty, вводят веб-приложения". Я сказал бы, что большинство веб-приложений больше похоже на "Word" тогда, они похожи на Exchange.
И да, я знаю, что существует WCF и сервисы SOAP и подобные вещи, но те - обычно просто "среднее изделие" для материала типа "clienty".
Sun, с другой стороны, является, прежде всего, компанией сервера. Их программное обеспечение не является точно самым большим когда дело доходит до пользовательского интерфейса (это не небольшое на Unix... просто Солярис.. Mac OS X основан на Unix, и это имеет феноменальный пользовательский интерфейс, различие между этими двумя - то, что Sun действительно не заботится так о UI, как Apple делает). Они даже продают ТОНКИЕ КЛИЕНТЫ, которые пытаются продвинуть все на сервер.
Так... в любом случае... Microsoft является главным образом клиентской компанией, и Sun является главным образом компанией сервера.
, Когда Вы пишете программное обеспечение сервера, надежность является большой вещью. Это огромно. Если почтовый сервер отказывает, люди не получают электронную почту, и бизнес останавливается. Так, удостоверение, что сервер может разумно обработать большинство ошибок, которые могут произойти, является большой частью продажи почтового сервера.
С клиентским программным обеспечением. надежность важна, но не где около AS, важного, как это с программным обеспечением сервера. Пока большая часть основной работы сценариев строки, люди счастливы. Во многих случаях сумасшедшие граничные сценарии могут просто быть проигнорированы или обработаны в общем.
Один ключ к тому, чтобы быть супер надежным удостоверяется, что Вы обрабатываете все возможные пограничные случаи, которые могут произойти. Что происходит, если мы не можем открыть файл базы данных, потому что он заблокирован другим процессом, или у нас нет разрешения считать его? Что, если у нас заканчивается память или дисковое пространство? Что происходит, если питание выходит при выполнении этой процедуры?
С действительно высокими требованиями надежности, имея CAN контролируемых исключительных ситуаций быть полезным. Если существует сценарий, Вы не ожидали, и для Вашего бизнеса важно, чтобы Вы ожидали все, то наличие компилятора говорит Вам... "эй, что Вы не обработали RocketFuelExhaustedException", будет полезно.
Так, я думаю основа контролируемых исключительных ситуаций с точки зрения Sun как поставщик сервера.
К Microsoft, как клиентская компания, продающая инструменты разработчика разработчикам клиентского программного обеспечения, контролируемые исключительные ситуации, конечно, ужасно раздражают вещи, которые просто мешают реальной сделанной работе.
Это составляет мои 0,02$ так или иначе...
Исключениями являются 'по-видимому исключительные' события. В парадигмах .net никогда не должны происходить исключения (вот почему, у Вас есть методы как TryParse...), таким образом, имеет мало смысла быть вынужденным обработать события, которые не должны происходить так или иначе.