2015-01-20 6 views
7

Например, исключение типа: java.net.BindException может вызывать «уже использованный адрес» (пытается связать порт, который использует другая программа) или «Permission denied» (вы не используете имеют права root, чтобы открыть этот номер порта). Я не владею классом, который бросает BindException.различают исключения одного типа

Итак, что лучше всего отличить эти «разные» исключения с одним и тем же типом?

Я делаю это, но я не знаю, если это лучшая практика:

try { 
    //...some scary stuffs here 
} 
catch (BindException e){ 
      if (e.getMessage().contentEquals("Permission denied")){ 
       System.out.println("ERROR**You must be ROOT to bind that port address TCP:"+defaultPort); 
      } 
      else if (e.getMessage().contentEquals("Address already in use")){ 
       System.out.println("ERROR**Port TCP:"+defaultPort+" already in use by onother application"); 
      } 
      e.printStackTrace(); 
     } 
+1

Если вы делаете это в нескольких частях своего кода, я предлагаю вам принять его и поместить в свой класс, например, в класс утилиты. – ultrajohn

+0

Кроме того, я хотел бы сделать подкласс для каждого типа BindException. – ultrajohn

+0

нет; это, например, здесь; но tnx для совместной работы. –

ответ

5

Это зависит от многого. Если это код, который вы владеете или иметь доступ к и BindException не подходит, то вы должны создать свои собственные исключения:

public class PermissionDeniedException 

Можно даже сделать:

public class PermissionDeniedBindException extends BindException 

Однако, если это не ваш class, то либо библиотека, которую вы используете, не хочет, чтобы вы различали BindException и ожидаете, что вы будете вести себя определенным образом при получении исключения (т.е. просто продолжаете или всегда пытаетесь снова) ИЛИ это проблема в SDK. Если это будет позже, и этот проект будет открытым исходным кодом, я бы рекомендовал создать запрос на перенос.

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

+1

Кроме того, некоторые исключения выбрасываются с нулевым сообщением, поэтому предполагать, что это иначе, опасно. Вместо 'e.getMessage(). ContentEquals (« Permission denied »)', безопаснее и гибче использовать нулевую проверку и запускаетWith() следующим образом: 'e.getMessage()! = Null && e.getMessage() .startsWith («Permission denied») ' – gknicker

+0

Я не владею классом, который бросает это исключение. Этот класс - java.net.ServerSocket. Я думаю, что третий вариант, упомянутый в вашем ответе, звучит хорошо ... если библиотека java.net ничего не меняет, конечно. –

+1

Если вы не хотите изменять java.net API, я думаю, у вас нет выбора, кроме как продолжить то, что вы делаете. Лучшее, что вы можете сделать с этим, - это поставить все на свое место в своей кодовой базе, чтобы сделать вещи упорядоченными и последовательными. – ultrajohn

Смежные вопросы