Exception Handling - Part One

1. Do i need to create a new exception class ?

    When faced with choosing the type of exception to throw, you can either use one written by someone else — the Java platform provides a lot of exception classes you can use — or you can write one of your own. You should write your own exception classes if you answer yes to any of the following questions; otherwise, you can probably use someone else's.

    Do you need an exception type that isn't represented by those in the Java platform?
    Would it help users if they could differentiate your exceptions from those thrown by classes written by other vendors?
    Does your code throw more than one related exception?
    If you use someone else's exceptions, will users have access to those exceptions? A similar question is, should your package be independent and self-contained?
    
2.
Normally don't throw some exceptions which you don't have control(not part of your code), instead, you can create your own exceptions and catch the relevant exceptions fronm downstream
and throw your own exceptions, e.g. you can catch various exceptions from downstream when you send emails, but you just throw one "EmailException" in your program,
so the caller in your program will simply handle the "EmailException", and it can easily identify that this exception is thrown by the program code(can judge from the namespace or package name).

3.
In java, RuntinmeException is the unchecked exception, so it's not necessarily part of the method signiture, as there be various types of runtime exceptions thrown, normally you don't know how to handle all of them.

4.
When writting some method, if something is not expected, e.g. the input data is not right or not supported, you need to raise an exception to the caller, so that it knows what happened instead of getting some null or empty result.

e.g. in the following factory method:

    public static Car createCar(CarMaker carMaker, CarType carType) throws CarException {
        Car resultCar;

        if(carType == CarType.BMWCar){
            try{
                resultCar = carMaker.createCar();
                resultCar.init();
            } catch(CarMakingException carMakingException){
                throw new CarException("Failed to create a BMW Car", carMakingException);
            }
        } else {
            throw new RuntimeException("Car type not supported");
        }

        return resultCar;
    }

    a. We need to assert other types of cars, i.e. for not supported car types, we also need to handle properly instead of return a null object to the caller.
    b. If input data not valid, e.g. the car type is not supported here, then we will raise an error to the caller, so that it knows what happened essentially.
    
5.
Dont' try to catch all the possible exceptions.

In some case, you don't know how to handle the exceptions, for these exceptions, you don't know the implication,
then just leave it, it's fine that program crach or shut down suddenly due to these exceptions. We should not try to catch and handle in such case, it might be leaving the application keeping doig the wrong things and nobody will knows as it seems the exception is already handled "nicely".

6. Know clearly what are the implication of the exception

In case of exception, you can either exit the app or just write some error log or simply raise an warning alert to user in the GUI.

This really depends on the implication:
If the exception is fatal, e.g. the data might be massed up, then you have to exit the app and shut down it immediately.
If the exception is some merely a user error, then you can raise an alert in the GUI.
If the exception is not critical and it's a backgroud process, then program can simply wirte a exception log entry for that.

In other cases, it is the caller to depends how to handle the error appropriately.