Is it bad practice to throw multiple custom exceptions in Java?

No. It is good practice.

The only situation where multiple exceptions might be a (slightly) bad idea is if there is absolutely no possibility (ever!) of catching individual exceptions; i.e. the fine-grained exceptions won't serve any functional purpose. However, my opinion is that if you can make that assertion, then there is probably something wrong with the way that you / your team is using Java. And the counter-argument is that sensible use of multiple custom exceptions will help you to document the APIs ... even if you are never going to do more than catch-log-and-bail-out at runtime.

This is not to say that lots of custom exceptions will always be good:

• If you go overboard and create a separate exception for everything, then you are probably adding unnecessary complexity. (In a lot of cases, different exception messages are sufficient.)

• If you don't have a sensible inheritance hierarchy for your custom exceptions, then you may end up regretting it. (A well-designed hierarchy allows you to catch "classes" of exceptions, or declare methods as throwing them. It can make your code simpler.)

You should be able to create a custom exception class that extends the Exception class, for example:

class WordContainsException extends Exception
{
      // Parameterless Constructor
      public WordContainsException() {}

      // Constructor that accepts a message
      public WordContainsException(String message)
      {
         super(message);
      }
 }

Usage:

try
{
     if(word.contains(" "))
     {
          throw new WordContainsException();
     }
}
catch(WordContainsException ex)
{
      // Process message however you would like
}

Generally custom exceptions should be defined in the top level. Because, almost universally, these exceptions are part of the interface of the package or module.

If the user cannot see them, then how are they going to catch them separately? And if you don't want to catch them separately, then why would you need separate classes?

However, if you must, you can include them into a class for which they are required:

public class SeatReservationSystem {
    public static class ReservationFailedException {
        ... constructors taking a message ...
    }

    public static class SeatTakenException extends ReservationFailedException {
        ... constructors taking a message ...
    }

    public static class OutsideAgeException extends ReservationFailedException  {
        ... constructors taking a message ...
    }

    ....
}

After that you can create any method that returns them as required. Don't create methods that throw them as the compiler won't see those as exit points of the block you're in, and you'll get strange situations.

Here is some code to show what I mean:

// wrong
public static void throwRuntimeException() throws RuntimeException {
    throw new RuntimeException();
}

// correct, but dangerous
public static RuntimeException createRuntimeException() {
    return new RuntimeException();
}

public static void main(String[] args) {
    String initializeMeOrThrowException;
    if (new Random().nextBoolean()) {
        // compiler doesn't recognize that the method always throws an exception 
        throwRuntimeException();

        // this the compiler can understand, there is an explicit throw here:
        // throw createRuntimeException();

        // but this is the pitfall, it doesn't do anything:
        // createRuntimeException();
    } else {
        initializeMeOrThrowException = "Initialized!";
    }

    // Compiler error for throwRuntimeException and createRuntimeException without throws:
    // "The local variable initializeMeOrThrowException may not have been initialized"
    System.out.println(initializeMeOrThrowException); 
}

However, experience learns me that I forget the throws statement for the throw createException(...); method, and the stupid compiler doesn't warn me about that (even though the statement is utterly useless without it). So I try and not use either.

Note that I'm not certain if you should use exceptions for this. If your system is a reservation system, then refusing tickets is not that exceptional. Returning a ReservationResult makes more sense.

I will try to give a few examples in Java as I am unsure from the picture and your statement:

where you would declare multiple custom exceptions like so in a single class:

What you precisely mean with the declare multiple custom exceptions in a single class.

Interface

In Java you can either define a Interface and implement that and use it in typing like so:

interface CustomException {
   String getMessage();
}

Then create a class that implements it.

class ApplicationException implements CustomException {
  public String getMessage() {
    return "Uh oh..";
  }
}

And when you throw anything you can get away with catching only CustomException.

try {
   // do something
}
catch( CustomException ce) {
  // do something with the CustomException
}

Base class

The other way you can go is to extend one of the built in Exception classes like RuntimeException or just Exception itself.

class CustomException extends Exception {
  public CustomException(String message) {
    super(message);
  }
}

Then you can extend from that custom class and use it in typing as normal.

class ApplicationException extends CustomException {
  public ApplicationException(String message) {
    super(message);
  }
}

Then this works again like previously:

try {
   // do something
}
catch( CustomException ce) {
  // do something with the CustomException
}

Inside the catch you catch them all in one go. If you need to do different logic on different catches you can do separate catch blocks otherwise the other option you can do is:

try {
 // do something
}
catch ( ApplicationException | IllegalArgumentException e) {
  // do something with an error that is either a ApplicationException or a IllegalArgumentException
}

Non conventional

This I am putting here for completeness sake but it is not conventional. You could create one file in your project called Exception.java. Inside you can define as many classes as you want and you can refer to them by importing them but it is not the idiomatic way to write Java.

So inside Exception.java :

class CustomException extends Exception {
  public CustomException(String message) {
    super(message);
  }
}

class ApplicationException extends Exception {
  public ApplicationException(String message) {
    super(message);
  }
}

Hope this helps you out and continues you on your journey.

In the spirit of the question as asked:

You would have to catch the various exceptions within your method, and then throw a CustomException from your catch block. The ability for an exception to "wrap" around another exception is built in via the Exception class itself (see the Exception(Throwable cause) constructor).

public void method() throws IOException, CustomException {
    try {
        //Body of the method
    } catch (IllegalArgumentException | InstantiationException | IllegalAccessException e) {
        throw new CustomException(e);
    }
}

That said, IllegalArgumentException is not a checked exception, so you wouldn't have to declare it anyway.

Also worth pointing out, the above is based on you specifying that you want to create a custom exception. Another option is to declare in your throws clause some type that is a common base class of the various checked exceptions that might actually be thrown. For example, both of the checked exceptions in your list are subclasses of ReflectiveOperationException, so you could just say

public void method() throws IOException, ReflectiveOperationException {
    //Body of the method
}

The trade-off, of course, is that you're not being as informative to those writing code that calls your method, so that may limit the quality of their exception handlers. In the extreme, you could just say throws Thorwable, but this is pretty poor form.

Yes. There are two ways to do this:

Class hierarchies

This one only applies if you are the one designing the exceptions. If that doesn't describe this case, move on to the next chapter.

If you have, say, a user authentication API, you would presumably want to create a whole bevy of exceptions such as UserNotFoundException, IncorrectPasswordException, UserFrozenException, IpBlockedException, and more.

If you make sure all those exceptions extend a single exception type (AuthenticationException), like so:

public class AuthenticationException extends Exception {
    public AuthenticationException(String msg, Throwable cause) {
        super(msg, cause);
    }

    public AuthenticationException(String msg) {
        super(msg);
    }
}

public class UserNotFoundException extends AuthenticationException {
    public UserNotFoundException(String username) {
        super(username);
    }
}

// and so on

then a caller can choose, which is why this makes for such a great API design.

IF a caller needs to have custom reactions depending on what kind of authentication problem occurs, they can catch, say, UserNotFoundException. But if they don't particularly care, they can catch AuthenticationException.

Note that java itself does this, too. GeneralSecurityException is the common superclass, and yet most security-related methods throw a sizable list of subclasses of this, so that callers know exactly what kind of errors can occur, and can write handlers for specific errors, without forcing them to write a ton of catch blocks if they don't want to.

rethrow

An alternate solution is that you bundle up exceptions into your own custom type.

To do this, first write an exception (or use an existing one, but that's rarely stylistically the right move). Then, write a catch block and wrap all those weird, unrelated exceptions into this newly created one, making sure to use the 'cause' system:

public class CustomException { // find a better name
    public CustomException(String msg, Throwable cause) {
        super(msg, cause);
    }

    public CustomException(String msg) {
        super(msg);
    }

    public CustomException(Throwable cause) {
        super(cause);
    }
}

public void myMethod() throws CustomException {
    try {
        // code here
    } catch (ApiException | ClassNotFoundException | NoSuchMethodException | IllegalAccessException e) {
        throw new CustomException(e);
    } catch (InvocationTargetException e) {
        throw new CustomException(e.getCause();
    }
}

but note how your suggestion that you just want to fire-and-forget is causing your API design to be problematic. For example, wrapping an InvocationTargetException like this is rather hostile to your API consumers; InvocationTargetException is itself a wrapper, so now you've got wrappers-in-wrappers-in-wrappers and that's just ugly and makes it real hard for calling code to even try to deal with problems in a pinpoint fashion. There really is no easy way around reading the APIs you use and understanding why it throws the various exceptions that it throws.

NB: If you can, the class hierarchies solution is a much better way to do this; but it does require that you are in control of the code that's throwing them.