Exception handling in Java: Advanced features and types

Published on:

My instance revealed just one trigger. Exceptions thrown from non-trivial real-world purposes could include intensive chains of many causes. You’ll be able to entry these causes by using a loop reminiscent of the next:

catch (Exception exc)
{
   Throwable t = exc.getCause();
   whereas (t != null)
   {
      System.out.println(t);
      t = t.getCause();
   }
}

Attempt-with-resources

Java purposes typically entry information, database connections, sockets, and different assets that depend upon associated system assets (e.g., file handles). The shortage of system assets implies that they need to finally be launched, even when an exception happens. When system assets aren’t launched, the appliance finally fails when making an attempt to amass different assets, as a result of no extra associated system assets can be found.

- Advertisement -

In my introduction to exception dealing with fundamentals, I discussed that assets (really, the system assets on which they rely) are launched in a lastly block. This will result in tedious boilerplate code, such because the file-closing code that seems under:

lastly
{
   if (fis != null)
      attempt
      {
         fis.shut();
      }
      catch (IOException ioe)
      {
         // ignore exception
      }
   if (fos != null)
      attempt
      {
         fos.shut();
      }
      catch (IOException ioe)
      {
         // ignore exception
      }
}

Not solely does this boilerplate code add bulk to a classfile, the tedium of writing it would result in a bug, maybe even failing to shut a file. JDK 7 launched try-with-resources to beat this downside.

The fundamentals of try-with-resources

The try-with-resources assemble robotically closes open assets when execution leaves the scope by which they have been opened and used, whether or not or not an exception is thrown from that scope. This assemble has the next syntax:

attempt (useful resource acquisitions)
{
   // useful resource utilization
}

The attempt key phrase is parameterized by a semicolon-separated checklist of resource-acquisition statements, the place every assertion acquires a useful resource. Every acquired useful resource is on the market to the physique of the attempt block, and is robotically closed when execution leaves this physique. In contrast to a daily attempt assertion, try-with-resources doesn’t require catch blocks and/or a lastly block to comply with attempt(), though they are often specified.

- Advertisement -

Take into account the next file-oriented instance:

attempt (FileInputStream fis = new FileInputStream("abc.txt"))
{
   // Do one thing with fis and the underlying file useful resource.
}

On this instance, an enter stream to an underlying file useful resource (abc.txt) is acquired. The attempt block does one thing with this useful resource, and the stream (and file) is closed upon exit from the attempt block.

Utilizing ‘var’ with ‘try-with-resources’

JDK 10 launched assist for var, an identifier with particular which means (i.e., not a key phrase). You need to use var with try-with-resources to scale back boilerplate. For instance, you may simplify the earlier instance to the next:

attempt (var fis = new FileInputStream("abc.txt"))
{
   // Do one thing with fis and the underlying file useful resource.
}

Copying a file in a try-with-resources context

Within the earlier article, I excerpted the copy() technique from a file-copy utility. This technique’s lastly block incorporates the file-closing boilerplate offered earlier. Itemizing 8 improves this technique through the use of try-with-resources to deal with the cleanup.

Itemizing 8. Copy.java

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.FileOutputStream;
import java.io.IOException;

public class Copy
{
   public static void foremost(String[] args)
   {
      if (args.size != 2)
      {
         System.err.println("utilization: java Copy srcfile dstfile");
         return;
      }

      attempt
      {
         copy(args[0], args[1]);
      }
      catch (IOException ioe)
      {
         System.err.println("I/O error: " + ioe.getMessage());
      }
   }

   static void copy(String srcFile, String dstFile) throws IOException
   {
      attempt (FileInputStream fis = new FileInputStream(srcFile);
           FileOutputStream fos = new FileOutputStream(dstFile))
      {
         int c;
         whereas ((c = fis.learn()) != -1)
            fos.write(c);
      }
   }
}

copy() makes use of try-with-resources to handle supply and vacation spot file assets. The spherical bracketed-code following attempt makes an attempt to create file enter and output streams to those information. Assuming success, its physique executes, copying the supply file to the vacation spot file.

See also  Apple, Nvidia, and others trained their AI on YouTube content without user consent or knowledge

Whether or not an exception is thrown or not, try-with-resources ensures that each information are closed when execution leaves the attempt block. As a result of the boilerplate file-closing code that was proven earlier isn’t wanted, Itemizing 8’s copy() technique is way easier and simpler to learn.

Designing useful resource courses to assist try-with-resources

The try-with-resources assemble requires {that a} useful resource class implement the java.lang.Closeable interface or the JDK 7-introduced java.lang.AutoCloseable superinterface. Pre-Java 7 courses like java.io.FileInputStream applied Closeable, which presents a void shut() technique that throws IOException or a subclass.

- Advertisement -

Beginning with Java 7, courses can implement AutoCloseable, whose single void shut() technique can throw java.lang.Exception or a subclass. The throws clause has been expanded to accommodate conditions the place you may want so as to add shut() strategies that may throw exceptions exterior of the IOException hierarchy; for instance, java.sql.SQLException.

Itemizing 9 presents a CustomARM utility that reveals you easy methods to configure a customized useful resource class with the intention to use it in a try-with-resources context.

Itemizing 9. CustomARM.java

public class CustomARM
{
   public static void foremost(String[] args)
   {
      attempt (USBPort usbp = new USBPort())
      {
         System.out.println(usbp.getID());
      }
      catch (USBException usbe)
      {
         System.err.println(usbe.getMessage());
      }
   }
}

class USBPort implements AutoCloseable
{
   USBPort() throws USBException
   {
      if (Math.random() < 0.5)
         throw new USBException("unable to open port");
      System.out.println("port open");
   }

   @Override
   public void shut()
   {
      System.out.println("port shut");
   }

   String getID()
   {
      return "some ID";
   }
}

class USBException extends Exception
{
   USBException(String msg)
   {
      tremendous(msg);
   }
}

Itemizing 9 simulates a USB port in which you’ll open and shut the port and return the port’s ID. I’ve employed Math.random() within the constructor with the intention to observe try-with-resources when an exception is thrown or not thrown.

Compile this itemizing and run the appliance. If the port is open, you’ll see the next output:

port open
some ID
port shut

If the port is closed, you may see this:

unable to open port

Suppressing exceptions in try-with-resources

If you happen to’ve had some programming expertise, you might need observed a possible downside with try-with-resources: Suppose the attempt block throws an exception. This assemble responds by invoking a useful resource object’s shut() technique to shut the useful resource. Nonetheless, the shut() technique may also throw an exception.

When shut() throws an exception (e.g., FileInputStream‘s void shut() technique can throw IOException), this exception masks or hides the unique exception. Plainly the unique exception is misplaced.

The truth is, this isn’t the case: try-with-resources suppresses shut()‘s exception. It additionally provides the exception to the unique exception’s array of suppressed exceptions by invoking java.lang.Throwable‘s void addSuppressed(Throwable exception) technique.

Itemizing 10 presents a SupExDemo utility that demonstrates easy methods to repress an exception in a try-with-resources context.

Itemizing 10. SupExDemo.java

import java.io.Closeable;
import java.io.IOException;

public class SupExDemo implements Closeable
{
   @Override
   public void shut() throws IOException
   {
      System.out.println("shut() invoked");
      throw new IOException("I/O error in shut()");
   }

   public void doWork() throws IOException
   {
      System.out.println("doWork() invoked");
      throw new IOException("I/O error in work()");
   }

   public static void foremost(String[] args) throws IOException
   {
      attempt (SupExDemo supexDemo = new SupExDemo())
      {
         supexDemo.doWork();
      }
      catch (IOException ioe)
      {
         ioe.printStackTrace();
         System.out.println();
         System.out.println(ioe.getSuppressed()[0]);
      }
   }
}

Itemizing 10’s doWork() technique throws an IOException to simulate some type of I/O error. The shut() technique additionally throws the IOException, which is suppressed in order that it doesn’t masks doWork()‘s exception.

The catch block accesses the suppressed exception (thrown from shut()) by invoking Throwable‘s Throwable[] getSuppressed() technique, which returns an array of suppressed exceptions. Solely the primary component is accessed as a result of just one exception is suppressed.

See also  The open source community strikes back

Compile Itemizing 10 and run the appliance. You must observe the next output:

doWork() invoked
shut() invoked
java.io.IOException: I/O error in work()
        at SupExDemo.doWork(SupExDemo.java:16)
        at SupExDemo.foremost(SupExDemo.java:23)
        Suppressed: java.io.IOException: I/O error in shut()
                at SupExDemo.shut(SupExDemo.java:10)
                at SupExDemo.foremost(SupExDemo.java:24)

java.io.IOException: I/O error in shut()

A number of catch blocks (multi-catch)

Beginning in JDK 7, it’s attainable to codify a single catch block that catches multiple sort of exception. The aim of this multi-catch characteristic is to scale back code duplication and scale back the temptation to catch overly broad exceptions (for example, catch (Exception e)).

Suppose you’ve developed an utility that provides you the flexibleness to repeat knowledge to a database or file. Itemizing 11 presents a CopyToDatabaseOrFile class that simulates this example, and demonstrates the issue with catch block code duplication.

Itemizing 11. CopyToDatabaseOrFile.java

import java.io.IOException;

import java.sql.SQLException;

public class CopyToDatabaseOrFile
{
   public static void foremost(String[] args)
   {
      attempt
      {
         copy();
      }
      catch (IOException ioe)
      {
         System.out.println(ioe.getMessage());
         // further handler code
      }
      catch (SQLException sqle)
      {
         System.out.println(sqle.getMessage());
         // further handler code that is equivalent to the earlier handler's
         // code
      }
   }

   static void copy() throws IOException, SQLException
   {
      if (Math.random() < 0.5)
         throw new IOException("can not copy to file");
      else
         throw new SQLException("can not copy to database");
   }
}

JDK 7 overcomes this code duplication downside by letting you specify a number of exception varieties in a catch block the place every successive sort is separated from its predecessor by putting a vertical bar (|) between these varieties:

attempt
{
   copy();
}
catch (IOException | SQLException iosqle)
{
   System.out.println(iosqle.getMessage());
}

Now, when copy() throws both exception, the exception can be caught and dealt with by the catch block.

When a number of exception varieties are listed in a catch block’s header, the parameter is implicitly considered ultimate. In consequence, you can’t change the parameter’s worth. For instance, you can’t change the reference saved within the earlier code fragment’s iosqle parameter.

Ultimate re-throw

Beginning in JDK 7, the Java compiler is ready to analyze re-thrown exceptions extra exactly than in earlier Java variations. This characteristic solely works when no assignments are made to a re-thrown exception’s catch block parameter, which is taken into account to be successfully ultimate. When a previous attempt block throws an exception that’s a supertype/subtype of the parameter’s sort, the compiler throws the caught exception’s precise sort as an alternative of throwing the parameter’s sort (as was finished in earlier Java variations).

The aim of this ultimate re-throw characteristic is to facilitate including a attemptcatch assertion round a block of code to intercept, course of, and re-throw an exception with out affecting the statically decided set of exceptions thrown from the code. Additionally, this characteristic helps you to present a typical exception handler to partially deal with the exception near the place it’s thrown, and supply extra exact handlers elsewhere that deal with the re-thrown exception. Take into account Itemizing 12.

Itemizing 12. MonitorEngine.java

class PressureException extends Exception
{
   PressureException(String msg)
   {
      tremendous(msg);
   }
}

class TemperatureException extends Exception
{
   TemperatureException(String msg)
   {
      tremendous(msg);
   }
}

public class MonitorEngine
{
   public static void foremost(String[] args)
   {
      attempt
      {
         monitor();
      }
      catch (Exception e)
      {
         if (e instanceof PressureException)
            System.out.println("correcting strain downside");
         else
            System.out.println("correcting temperature downside");
      }
   }

   static void monitor() throws Exception
   {
      attempt
      {
         if (Math.random() < 0.1)
            throw new PressureException("strain too excessive");
         else
         if (Math.random() > 0.9)
            throw new TemperatureException("temperature too excessive");
         else
            System.out.println("all is properly");
      }
      catch (Exception e)
      {
         System.out.println(e.getMessage());
         throw e;
      }
   }
}

Itemizing 12 simulates the testing of an experimental rocket engine to see if the engine’s strain or temperature exceeds a security threshold. It performs this testing by way of the monitor() helper technique.

See also  Red Hat’s Podman AI Lab supports developer adoption of genAI

monitor()‘s attempt block throws PressureException when it detects a strain excessive, and throws TemperatureException when it detects a temperature excessive. (As a result of that is solely a simulation, random numbers are used — the java.lang.Math class’s static double random() technique returns a random quantity between 0.0 and (virtually) 1.0.) The attempt block is adopted by a catch block designed to partially deal with the exception by outputting a warning message. This exception is then re-thrown in order that monitor()‘s calling technique can end dealing with the exception.

Earlier than JDK 7 you couldn’t specify PressureException and TemperatureException in monitor()‘s throws clause as a result of the catch block’s e parameter is of sort java.lang.Exception and re-throwing an exception was handled as throwing the parameter’s sort. JDK 7 and successor JDKs have made it attainable to specify these exception varieties within the throws clause as a result of their compilers can decide that the exception thrown by throw e comes from the attempt block, and solely PressureException and TemperatureException might be thrown from this block.

As a result of now you can specify static void monitor() throws PressureException, TemperatureException, you possibly can present extra exact handlers the place monitor() is known as, as the next code fragment demonstrates:

attempt
{
   monitor();
}
catch (PressureException pe)
{
   System.out.println("correcting strain downside");
}
catch (TemperatureException te)
{
   System.out.println("correcting temperature downside");
}

Due to the improved sort checking provided by ultimate re-throw in JDK 7, supply code that compiled below earlier variations of Java may fail to compile below later JDKs. For instance, think about Itemizing 13.

Itemizing 13. BreakageDemo.java

class SuperException extends Exception
{
}

class SubException1 extends SuperException
{
}

class SubException2 extends SuperException
{
}

public class BreakageDemo
{
   public static void foremost(String[] args) throws SuperException
   {
      attempt
      {
         throw new SubException1();
      }
      catch (SuperException se)
      {
         attempt
         {
            throw se;
         }
         catch (SubException2 se2)
         {
         }
      }
   }
}

Itemizing 13 compiles below JDK 6 and earlier. Nonetheless, it fails to compile below later JDKs, whose compilers detect and report the truth that SubException2 is rarely thrown within the physique of the corresponding attempt assertion. It is a small downside that you’re unlikely to come across in your applications, and a worthwhile trade-off for having the compiler detect a supply of redundant code. Eradicating redundancies leads to cleaner code and smaller classfiles.

StackWalker and the StackWalking API

Acquiring a stack hint by way of Thread‘s or Throwable‘s getStackTrace() technique is dear and impacts efficiency. The JVM eagerly captures a snapshot of all the stack (apart from hidden stack frames), even whenever you solely want the primary few frames. Additionally, your code will in all probability need to course of frames which are of no curiosity, which can be time-consuming. Lastly, you can’t entry the precise java.lang.Class occasion of the category that declared the tactic represented by a stack body. To entry this Class object, you’re pressured to increase java.lang.SecurityManager to entry the protected getClassContext() technique, which returns the present execution stack as an array of Class objects.

JDK 9 launched the java.lang.StackWalker class (with its nested Choice class and StackFrame interface) as a extra performant and succesful various to StackTraceElement (plus SecurityManager). To find out about StackWalker and its associated varieties, see my introduction to the StackWalking API.

In conclusion

This text completes my two-part introduction to Java’s exception dealing with framework. You may need to reinforce your understanding of this framework by reviewing Oracle’s Exceptions lesson within the Java Tutorials. One other good useful resource is Baeldung’s Exception dealing with in Java tutorial, which incorporates anti-patterns in exception dealing with.

- Advertisment -

Related

- Advertisment -

Leave a Reply

Please enter your comment!
Please enter your name here