status and error_type missing in KiteExceptions

@tahseen In order to handle the exception correctly we would require ALL the information. I don't see any cost benefit in omitting the code.

++ @sujith
@rakeshr I got the TokenException which I want to handle. As per the documentation error_type is not set. Only code and message is set.
No doubt, I can check for the class throwing the exception. But then, it is going to be a work-around.
Alternatively, if the JSON exception could have been thrown (from KiteResponseHandler.java) then it would have been better.

Pasted below is my Exception handling snippet with requirements mentioned in the code comment. Also pasted is the related java files/snippets from KiteConnect library.

Sample snippet for handling KiteException

try {
	User user = kiteConnect.generateSession(requestToken, zerodhaCredentials.get("api.secret"));
	kiteConnect.setAccessToken(user.accessToken);
	kiteConnect.setPublicToken(user.publicToken);
} catch (KiteException e) {
	logger.error("Unable to login", e);	// Here ONLY e.code and e.message is available.
	// I would like to re-login only if it's a TokenException with a 403 error code
	// as mentioned in the documentation.
}

Here is TokenException.java. I do not see error_type being set.

package com.zerodhatech.kiteconnect.kitehttp.exceptions;

/**
 * Denotes session is expired.
 */
public class TokenException extends KiteException {
    public TokenException(String message, int code) {
        super(message, code);
    }
}

Also in KiteException.java

package com.zerodhatech.kiteconnect.kitehttp.exceptions;

/**
 * This is the base exception class which has a publicly accessible message and code that
 * is received from Kite Connect api.
 */

public class KiteException extends Throwable {

    // variables
    public String message;
    public int code;

    // constructor that sets the message
    public KiteException(String message){
        this.message = message;
    }

    // constructor that sets the message and code
    public KiteException(String message, int code){
        this.message = message;
        this.code = code;
    }
}

And in the KiteResponseHandler.java you can see that only code and message is thrown.

    private KiteException dealWithException(JSONObject jsonObject, int code) throws JSONException {
        String exception = jsonObject.getString("error_type");

        switch (exception){
            // if there is a token exception, generate a signal to logout the user.
            case "TokenException":
                if(KiteConnect.sessionExpiryHook != null) {
                    KiteConnect.sessionExpiryHook.sessionExpired();
                }
                return  new TokenException(jsonObject.getString("message"), code);

            case "DataException": return new DataException(jsonObject.getString("message"), code);

            case "GeneralException": return new GeneralException(jsonObject.getString("message"), code);

            case "InputException": return new InputException(jsonObject.getString("message"), code);

            case "OrderException": return new OrderException(jsonObject.getString("message"), code);

            case "NetworkException": return new NetworkException(jsonObject.getString("message"), code);

            case "PermissionException": return new PermissionException(jsonObject.getString("message"), code);

            default: return new KiteException(jsonObject.getString("message"), code);
        }
    }

@tonystark

How would you like to use the raw string information? Is there a special use case?

No special use case as such. But it would be a generic approach instead of just giving the message.

As per the last code section you posted there is a 1:1 relation between the known error_type and the exception type it produces. If you really want you can do getClass().getName() and get the string name.

As mentioned in my first post, I can definitely handle it this way, but this is a work-around and not as per documentation.

Getting a class name is not hack.
The Kite Connect API is written in a generic way, the whole point of client libraries is to avoid using these raw values and consume API in the style of the language.

Ok. I was just going with the document. But then I agree, the document is also generic and not specific to any language.

The javakiteconnect is an open source repository. If you don't like it then you can fork the library and make changes as you wish.

This is always an option for any of the required fixes.

@tahseen, @rakeshr, @tonystark and @sujith Where can I get the list of status codes for different errors?
For eg.
403 - Session Expired
429 - NetworkException - Maximum allowed order modifications exceeded.