Exception Handling advantages and disadvantages

Exception Handling advantages and disadvantages

The following is a prototype of the fileinputstream constructor:

Public fileinputstream (string name) throws filenotfoundexception
This prototype is different from the similar prototype in C or C ++. the Java method and constructor must declare that they may "throw" exceptions when being called, the keyword used is "throws ". This exception prompt in the method prototype increases programming reliability. Obviously, this method reminds the method caller of possible exception conditions, so that the caller can properly handle these exceptions.
The following code illustrates how we capture and handle the filenotfoundexception exception:

Try
...{
Fileinputstream FCM = new fileinputstream (ARGs [0]);
// Other code here...
} Catch (filenotfoundexception fnfe)
...{
System. Out. println ("file:" + ARGs [0] + "Not found. Aborting .");
System. Exit (1 );
}

Java Exception Handling also has some other excellent features, such as checking exceptions, user-defined exceptions, and the new Java logging API (Java logging API) introduced in JDK 1.4 ).
All subclasses of Java. Lang. Exception belong to checkable exceptions. Checked exception is an exception that must be thrown by the method that throws the exception. This exception must be caught or thrown to the caller.
User-defined exceptions are custom exception classes that extend the java. Lang. exception class. Excellent Java programs require custom exception encapsulation, reporting, and handling of their own unique situations. The latest Java logging API (logging API) records exceptions in a centralized manner.

Not good

Java exception handling is poor in two situations: Misuse of unchecked exceptions and catchall constructor. Both methods make the problem complicated.
A type of exception is a subclass of runtimeexception, which is not checked by the compiler. For example, nullpointerexception and arraystoreexception are instances of this type of exception. Programmers can subclass runtimeexception to avoid the restriction of checking exceptions, so that the methods that generate these exceptions are used by their callers. Professional development teams should only be allowed to do so in rare cases. The catchall constructor is a bad habit of handling 2nd types of exceptions. The so-called "catchall constructor" is an exception capture code module that can handle all possible exceptions thrown to it.
The following are examples of catchall processors:

Try
...{
// Code here with checked exceptions
} Catch (throwable T)
...{
T. printstacktrace ();
}

I have to admit that I have used this technology when writing General programs. However, this type of constructor must be avoided when writing key programs, this can be done unless they are authorized to work with the central error processor. In addition, the catchall constructor is only a mechanism to speed up programming by avoiding error processing.
One disadvantage of exception handling is that it is difficult to adopt an excellent error handling policy. Recovery from low-volume memory status, write errors, algorithm errors, and other exceptions are not easily solved. You can try common technologies such as recycling, garbage collection, and reminding users to cope with the above situation.

Bad

Similar to many Java features and their APIs, Java's Exception Handling Mechanism also has a funny error in the "Overlord hard bow" class. For example, in order to throw an exception, we did not hesitate to use the keyword "new" to allocate memory for it. I don't know how many times I have repeatedly hit the wall in the face of serious compilers because of such errors. In this case, we are all waiting for the language instead of letting the language be used by us.
I have discussed several defects in exception handling in my written Java pitfalls book. For example, processing outofmemoryerrors is one of them. This process is: Use the finally module to close the file, parse the exception to get the problematic method and code line. The biggest defect in this process is that outofmemoryerror needs to be captured, but this exception is not checkable! Think about it. Memory depletion is quite common. Any program closely related to memory usage should capture and handle this error.
Finally, let's consider two features that are not yet part of the Java exception handling mechanism. First, the current situation is that after you successfully handle the exception, you cannot return to the place you just left. The setjmp () and longjmp () functions in C language can implement this feature. Java should have the corresponding versions of these two functions, we can also use the "resume" keyword to implement it.
The second unimplemented feature is the global exception processor. The comparison object is set_new_handler () in C ++ (). For example, during programming, even if the outofmemoryerror exception is worse than that of Java. lang. the error subclass is more common, but we can also use a global processor for the outofmemoryerror exception. This effect is much better than the normal checkable exception. If you are very concerned about these features, you can make your own suggestion in Java Developer Connection: add these features on the Java platform!