Я полагаю, что VersionsApp (версия, которую вы установили) не поддерживает TLS 1.0, 1.1 или 1.2 и поддерживает только SSL 3.0. Попробуйте обновить клиента и обратиться в службу поддержки, если это не поможет.
Если вашим SVN-сервером является VisualSVN-сервер, вы также можете попробовать настроить уровни совместимости TLS / SSL .
Не ловите ничего, что Вы не готовы и способный обработать.
Так, имейте в распоряжении обработку исключений верхнего уровня для взрыва приложения путем, Вам нравится на непредвиденных исключительных ситуациях, и затем только поймайте материал, в котором Вы нуждаетесь (как близко к тому, где это могло бы происходить) получить функциональность, которая необходима.
И необходимо сделать только одну из двух вещей: на самом деле сделайте что-то, чтобы решать/работать вокруг проблемы или повторно бросить более описательное исключение, которое имеет перехваченную исключительную ситуацию как innerException
.
Править: Если Вам нужен a finally
блок (например, выпускать что-то, что Вы выделили в своем коде) и у Вас ничего нет полезным, чтобы сделать за любыми исключениями, которые могли бы открыться, та же логика применяется: просто не обрабатывайте их. Вместо этого используйте a catch { throw; }
повторно бросить исключение в более высокий уровень при сохранении всей информации об исключении в целости. (Или просто опустите блок выгоды, который я думаю/надеюсь, делает то же самое?)
Я пытаюсь поймать ТОЛЬКО те исключения, с которыми я могу иметь дело.
Я НЕНАВИЖУ код как это:
String s="12";
Integer i;
try {
i = Integer.parseInt(s);
} catch(ParseException pe) {
System.out.println("hihihihihihihi!!!);
}
То, что я особенно ненавижу, - то, что то, что это обычно делает, должно прервать поток так или иначе, потому что три строки позже будет доступ ко мне, который предположит что я! = пустой указатель.
Затем Вы считаете свой stacktrace и прокрутите и прокрутите и прокрутите сезам журнала, Вы находите первую ошибку signifant, которая заставила все остальное развалиться.
Мне жаль, что Java не вынудил меня поймать Исключения, что я не могу иметь дело с, так или иначе. Но то, что я могу сделать, является этим:
catch(Exception e) {
throw new RuntimeException(e);
}
И я объявляю много "бросков" в моих функциональных определениях.
Я все еще мечтаю о дне, где Eclipse автоматически откроет Debugger в корректной строке, когда это получит неперехваченное исключение. В тот день мой метод откроет корректную строку.
На других языках, как Smalltalk, я фиксирую только ошибки, которые я могу обработать. И я счастливо выдаю неперехваченные исключения, когда вход не оправдывает мои надежды.
Идея состоит в том, что я не хочу, чтобы ошибка была зарегистрирована или зарегистрирована. Я хочу зафиксированный.
Я всегда вставлял основную выгоду () как выгода последней инстанции:
int main( int argc, char** argv ) {
try {
Application application( argc, argv );
return application.result();
}
catch ( const std::exception& exception ) {
fprintf( stderr, "%s.\n", exception.what() );
}
}
В C# и Java я предпочитаю не ловить исключения вообще. Если я не могу избежать его, я сразу повторно бросаю Исключение на этапе выполнения.
Я буду всегда использовать самый жадный блок выгоды, который имеет самый большой необходимый объем, но всегда с самым определенным возможным типом исключительной ситуации. Так как результат блока выгоды, другой добавляет 99,99% случаев, я пытаюсь сохранить полный метод в блоке попытки.
Мне нравится пытаться разделить мой код обработки исключений от моего другого кода, таким образом, я обычно создаю вспомогательный метод, который делает фактическую логику, и внешний метод просто имеет дело с обработкой исключений. Я всегда думал, что это дает коду чистый взгляд и делает его более читаемым.
public void stuff() throws MyException
{
try
{
tryStuff();
}
catch (SomeLibraryException e)
{
logger.log("Some message happened", e);
throw new MyException(e);
}
}
public void tryStuff() throws SomeLibraryException
{
// Do things in here that could throw exceptions
}
Мне нравится ловить вокруг обработчиков в контроллере, которые обрабатывают события, запущенные из представления. Если исключения дают сильную гарантию безопасности, это - полезная точка выгоды, потому что это - достаточно высокий уровень для создания отчетов об ошибке, и обработчики являются обычно атомарными и связанными с чем-то, что пользователь только что сделал так, надо надеяться, они смогут разработать то, что продолжается.
void Controller::on_edit_entity( const Entity& entity ) {
try {
Command::ptr command = new EditEntityCommand( entity );
push_command( command );
}
catch ( const std::exception& exception ) {
fprintf( stderr, "%s.\n", exception.what() );
}
}
В Приложении Windows Delphi основной цикл обработки сообщений для Вашего приложения (т.е. у основания стека вызовов) обрабатывает Ваши исключения путем показа окна сообщения. По-моему, это - лучшее место для обрабатывания исключений.
Путем ловли исключений в собственных методах для единственной цели показать окно сообщения пользователю, Вы отклоняете любой код, называя Ваш метод знания, что исключение на самом деле произошло и что метод заражает отказавший.
Я только обработал бы исключение если:
Два места: