Java – how do you know all the exceptions that a method can throw

Is there any way to get some details about the exception security of Java standard classes? Mainly using C and C #, I am confused about the Java exception specification, so I need to know the correct way to handle exceptions

More specifically, let's consider ServerSocket Once the object is constructed, it starts listening for incoming connections Then, you should use accept () to accept the connection (if someone tries to connect)

If you previously configured the server socket with setsotimeout(), a change will occur, that is, accept() will throw a sockettimeoutexception because no one is trying to connect within the specified time period Never mind, the server socket is still available, so you call accept () again

But sockettimeoutexception is not the only thing that accept () might throw What do all other exceptions mean? If I use two catch clauses to call accept (): for sockettimeoutexception and IOException, can I safely use the relevant ServerSocket instance after entering the IOException clause?

I am very grateful for the Java scope and ServerSocket - specific answers

Solution

It is not safe to reuse the object For such a problem, I always consider a source, which is why it is open

So if you look at that: http://kickjava.com/src/java/net/ServerSocket.java.htm , you will notice that in accept (), socketexception (inherited from IOException) is thrown if the socket is closed or no longer bound Both states indicate that the ServerSocket is no longer valid

Therefore, for this class, usually, if it fails due to an exception, always try to close the ServerSocket normally in the finally block, and then recreate it

In addition, within your Java scope: always look at the source code and understand what the interface is doing If it is a task - critical write test, it can reproduce the behavior (it should not be easy for such a low-level API)

Finally – has java been doing this? no Some classes are stateless, some are not (such as ServerSocket), some are thread safe, and some are not And you need to understand - whether from the documentation or (mostly) from the code - that the state they build is to understand what to do when an exception hits you from the main path

Most people curse checked Java exceptions because most Java exceptions (like most ioexceptions) cannot be recovered in a meaningful way Most of the time, they argue, you can't understand every thin case This is why many complex frameworks may retry twice or three times. If they think so, they will eventually throw runtimeException to the top framework layer There, they create something useful (a meaningful error provides context) and record all the details they have, which is a huge stack trace in most cases Many developers worry about the vast amount of knowledge resources

So what would you do if you couldn't recover from an untested corner problem? Throw (possibly some subclasses of runtimeException) the most meaningful stack trace, annotated with all the context you have Set up monitoring If you encounter a common problem, please fix it