В последнее время для персистенси предпочитаю использовать MyBatis 3 на аннотациях. Прикрутил к нему плагин для FreeMarker, и всё вообще идеально. Никаких сложных statefull фреймворков, всё на кончиках пальцев, и не многословно )
Часто бывает надо написать код, в котором 100% никогда не будет исключения (а если будет, то это уже сигнал к тому, что программа в этом окружении вообще неработоспособна. Например, UnsupportedCharacterEncoding), но который требует обрамления в try-catch.
Ещё бывает ситуация, в которой хочется на некоторый блок действий глобально повесить try-catch(Throwable) и если произойдет любое исключение, считать, что операция в целом зафейлилась. А не разбираться с каждым конкретным исключением, которое может случиться внутри этого блока.
> Никто не мешает заворачивать их вызовы в try/catch и пробрасывать дальше как unchecked
Только это и остаётся. Но это замусоривает код. Возвращаясь к примеру с UnsupportedCharacterEncoding, можно отметить, что если нужно написать метод, который занимает 5 строчек, а теперь приходится к нему добавить еще 5 строк try-catch-rethrow RuntimeException, то это же чистый мусор.
Ну и конечно же, наличие checked исключений и легкость избавления от них пустым catch-блоком побуждает начинающих делать это в больших количествах.
Про пункт с не очень опытным программистом. Эта проблема решаема статическим анализатором (и в IDE?), который бы говорил «чувак, возможно ты пропустил исключение здесь!».
Стиль хорош, но все-таки есть непонятные места. Я вроде в контексте, но уж очень много пропусков в логических цепочках. В конце как минимум нужно дописать то, что получилось в виде «а теперь мы можем сделать то-то и то-то таким вот образом». И пример кода, который работает.
По-моему, блокировка не лучший способ решения проблемы. Тут скорее всего надо делать просто транзакцию, которую потом можно откатить в случае чего. Но в этом случае АПИ тоже должен поддерживать некий откат, т.к. при конфликтующих транзакциях коммит не пройдёт, надо сделать откат в АПИ, и далее повторить попытку. Поправьте плз, если это решение плохо.
Попробуйте просто поискать вконтакте по записям. Часто бывают объявления от реальных людей (не репосты ссылок на сайты типа avito), дальше можно просто списываться с человеком. Есть еще пара групп вконтакте, которые называются что-то вроде «Без посредников»: они закрытые (доступ дают в течение дня-двух) и там банят агентов. Там каждый день появляются объявления. За 1-2 недели вполне можно найти несколько подходящих вариантов, ну и далее посмотреть их, выбрав один самый лучший для вас.
Действительность документов собственника проверить можно (и нужно) при личной встрече. Если сдают квартиру родственника, то можно спросить документы, подтверждающие родство (свидетельство о рождении, например, если дочь поменяла фамилию после свадьбы).
Это здорово, что в 8 появились! А я смотрел в доках к семёрке, поэтому и не увидел. Но всё равно пока придётся уж иметь в виду ручные реализации деления и сравнения, поддержка семёрки всё-таки желательная вещь сейчас.
Эта операция (инвертирование знака) проецирует пространство значений [0;2^32-1] на [-2^31;2^31-1] для обоих операндов. Далее производится обычное сравнение. Например, было число -1 (0xffffffff), оно станет 0x7fffffff. Было число 10 (0x0000000a), станет -10 (0x8000000a). 0x7fffffff > 0x8000000a.
Оп-па, а я и забыл про rotateLeft-Right. Спасибо. А про Integer(Long).compare(divide)Unsigned() не понял — в стандартной библиотеке вроде бы такого нет.
На мой взгляд, было бы технологичнее развернуть систему наподобие ejudge, чтобы можно было онлайн проверять свои решения. А задачка интересная, жаль, что не смогу поучаствовать :)
Пользуюсь следующим switch'ем:
Вариант 1. Метод всегда при любых условиях должен возвращать корректное значение. Проверка не нужна. Assert тоже не нужен.
Вариант 2. Метод может вернуть некорректное значение, но логика приложения построена таким образом, что этой ситуации в принципе не должно происходить. Сталю Assert — программа упадёт сразу после нарушения инварианта.
Вариант 3. Метод может вернуть некорректное значение при одном из допустимых вариантов использования. Нужно обработать этот случай.
Дополнительно: метод (или некоторый кусок кода) уже обработан по одному из вышеперечисленных сценариев, но я знаю, что этот код в принципе может упасть (ну вот кажется, что такое возможно). Однако я могу локализовать проблему вида «этот кусок кода полностью не сработал» и обработать её именно в таком представлении. В этом случае я ставлю на весь этот кусок дополнительный try-catch (Throwable) с логированием исключения и обработкой ситуации «не понятно, что случилось, но этот кусок кода не сработал». Соответственно, если мы имеем дело с мобильным приложением, то в этом месте также нужно реализовать отправку на сервер разработчика этого события.
Ещё бывает ситуация, в которой хочется на некоторый блок действий глобально повесить try-catch(Throwable) и если произойдет любое исключение, считать, что операция в целом зафейлилась. А не разбираться с каждым конкретным исключением, которое может случиться внутри этого блока.
> Никто не мешает заворачивать их вызовы в try/catch и пробрасывать дальше как unchecked
Только это и остаётся. Но это замусоривает код. Возвращаясь к примеру с UnsupportedCharacterEncoding, можно отметить, что если нужно написать метод, который занимает 5 строчек, а теперь приходится к нему добавить еще 5 строк try-catch-rethrow RuntimeException, то это же чистый мусор.
Ну и конечно же, наличие checked исключений и легкость избавления от них пустым catch-блоком побуждает начинающих делать это в больших количествах.
Про пункт с не очень опытным программистом. Эта проблема решаема статическим анализатором (и в IDE?), который бы говорил «чувак, возможно ты пропустил исключение здесь!».
Действительность документов собственника проверить можно (и нужно) при личной встрече. Если сдают квартиру родственника, то можно спросить документы, подтверждающие родство (свидетельство о рождении, например, если дочь поменяла фамилию после свадьбы).
ThreadLocalVariable -> ThreadLocalValueбыли бы тоже weak?Вариант 1. Метод всегда при любых условиях должен возвращать корректное значение. Проверка не нужна. Assert тоже не нужен.
Вариант 2. Метод может вернуть некорректное значение, но логика приложения построена таким образом, что этой ситуации в принципе не должно происходить. Сталю Assert — программа упадёт сразу после нарушения инварианта.
Вариант 3. Метод может вернуть некорректное значение при одном из допустимых вариантов использования. Нужно обработать этот случай.
Дополнительно: метод (или некоторый кусок кода) уже обработан по одному из вышеперечисленных сценариев, но я знаю, что этот код в принципе может упасть (ну вот кажется, что такое возможно). Однако я могу локализовать проблему вида «этот кусок кода полностью не сработал» и обработать её именно в таком представлении. В этом случае я ставлю на весь этот кусок дополнительный try-catch (Throwable) с логированием исключения и обработкой ситуации «не понятно, что случилось, но этот кусок кода не сработал». Соответственно, если мы имеем дело с мобильным приложением, то в этом месте также нужно реализовать отправку на сервер разработчика этого события.