a new way to handle exceptions

[brodie]

well, i am working on a open source project named app4j, i designed this exception handling method, but i am not quite sure about it. so please give me some advice. the original post is here

1, use code to identify exception.
for app4j, there is only one exception type, the StandardException?(@see org.app4j.StandardException?) which is a runtime exception. codes are used to identify exceptions. one code one exception. and the exception information should be easily looked up by its code. this means app4j would easily support a global exception database. for development, i think iterate every exception is worthy. exceptions should be managed centrally.

2, register exception handlers for codes
when @Entry's attribute error set to true, the app4j would take the method as a exception handler, for example:

static final int ERROR_USER_EXISTS = 1000;
static final int ERROR_INVALID_INPUT = 1001;
@Entry(value="", error=true, codes={ERROR_USER_EXISTS, ERROR_INVALID_INPUT})
public void registerErrorHandler(Event e){
e.setForward("profile/register");
e.setErrorProcessed();
}
this method handles 2 exceptions, when register users, the user's name should be unique, so there is User exist exception, and it also handles user's invalid input error. if a code missing its handler, app4j has default handler to redirect request to error page.

3, replace checked exception to with a annotation @Error.
checked exceptions sometimes are necessary, especially for interfaces, if we omit a runtime exception, the program possibly crash. so if a interface method want to document its exception, in this way:

@Entry("register")
@Error({ERROR_USER_EXISTS})
public void register(Event e){
if(e.isReadonly()){
e.setForward("profile/register");
return;
}
String name = e.getParameter("name");
String password = e.getParameter("password");
String role = e.getParameter("role");

if(name != null && password != null && role != null){
if(profiles.get(name) != null){
e.setLastError(new StandardException(ERROR_USER_EXISTS, "User name exists"));
e.stop();
return;
}
Person p = new Person(e.getActor());
p.setName(name);
p.setPassword(password);
p.setRole(role);
this.profiles.put(p.getName(), p);

e.setAttribute(Actor.KEY, p, Event.Scope.SESSION);
e.setAttribute("user-name", p.getName());

e.setForward("profile/info");
}else{
if(name == null){
e.setLastError(new StandardException(ERROR_INVALID_INPUT, "User name can't be empty"));
}else if(password == null){
e.setLastError(new StandardException(ERROR_INVALID_INPUT, "User password can't be empty"));
}else if(role == null){
e.setLastError(new StandardException(ERROR_INVALID_INPUT, "User role can't be empty"));
}
e.stop();
}

}
with @Error, we specify the exception codes the method probably thrown, and app4j would look up the handler for the exception, if the handler is missing, the app would failed to install. in fact, for the next version of app4j, actions would compile at runtime, so the error handler would weave into the action.
@Error also supports java doc.

4, avoid try{...}catch(){...}.
App4j is based on event model, event popping from one action to another. when current action finds the execution preconditions are not satisfied, it will change the status of event, not throw a exception, the framework would detect that and stop event popping.

[r035198x]

What are the goals of the project?
How do I do finally?

[Tolls]

Where are your exception ids defined?

In general, and I don't know the goals of this thing, having a single exception that holds an exception id is Bad Practice, in that it doesn't utilise any of the existing exception handling mechanism.

What problem with exceptions is this trying to solve?

[brodie]

well, where to define the ids is a big problem. i am thinking on it.
i am building a project based on OSGi, and i am trying to adapt the other open source projects to bundles to make them work together, like jforum, jspwiki. so i need a universal exception handling method.

[Tolls]

Why?
Why do you need a universal mechanism?
Nothing you do will manage to wire up all the thousands and thousands of exceptions that exist out there into one id-based exception system.

OSGi has an exception handling system doesn't it?

[brodie]

i should not post codes here, let's just focus on the design.
the design is following 3 rules:
1, use a single runtime exception and error code replacing throwing different kind of exception.
2, avoid using try...catch, register exception handler for every error code.
3, use an annotation @Error, to make a method 's thrown exception must be handled and could be documented.

[brodie]

if i adapt the other projects, i believe it would be a complex system, so error code makes the exceptions manageable and traceable , i believe big systems are using this way, like windows, mysql. and error code is easy to make the system i18n.

[brodie]

in fact i am trying to separate error handling and business logic, i hope the final solution is create a central error database, and use xml to map the error handling. when website admin or developers encountered a exception, he could lookup the error database by code and find information there.

[Tolls]

Why do you want to remove try/catch?
Error handling is a part of business logic.
An id based exception mechanism makes for harder to follow code, as you no longer have nice simple exception classes that (hopefully) describe the problem encountered in their name.

I really don't see an id-based system being any easier with regards to i18n...it's all resource bundles anyway.

And finally...as mentioned above. How do you handle "finally"?

[brodie]

thanks for your reply,
i think a typical java web application could be layered as Action, Service, Dao.
and exceptions could be categorized as recoverable and unrecoverable,
if we want the system to be neat and tidy, we need to define which layer to throw exception and which layer to handle it and how,
for the unrecoverable ones which including java.lang.Error, these exceptions could be only logged or redirect to error page, like database server is down.
i think those exceptions are not part of business logic. but as you said the recoverable exception handling indeed is part of business logic.
so here i made this assumption, most web application exceptions are unrecoverable, log and redirect to error page are the only way to handle them.

i am avoiding use try/catch, so i could use a declarative way to handle the unrecoverable exception.
about finally, i believe its usage mostly related to IO, it should in Dao layer, the new exception handling method would apply for Action and service layer.

[Tolls]

Why not then go the Spring/Hibernate route and simply go for RuntimeExceptions then?

I'm really having a hard time understanding what problem this is attempting to solve...