[ https://jira.jboss.org/jira/browse/JBPM-2682?page=com.atlassian.jira.plug... ] Peter Horvath updated JBPM-2682: -------------------------------- Description: Currently error conditions are signaled using a single exception type, JbpmException. Using problem specific exception subclasses would make it possible for the client code to deal with different error conditions differently . Example - current GetOutcomes command implementation: package org.jbpm.pvm.internal.cmd; ... public class GetOutcomes implements Command<Set<String>> { ... public Set<String> execute(Environment environment) { DbSession dbSession = environment.get(DbSession.class); TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId)); if (task==null) { throw new JbpmException("task "+taskId+" doesn't exist"); } ... Introducing problem specific exception subclasses would allow client code to handle errors much better: public Set<String> execute(Environment environment) { DbSession dbSession = environment.get(DbSession.class); TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId)); if (task==null) { throw new TaskDoesNotExistException("task "+taskId+" doesn't exist"); } for example if a custom TaskDoesNotExistException (public class TaskDoesNotExistException extends JbpmException) was thrown in GetOutcomes.execute when a task is not found, then the caller code would be able to distinguish this problem from say a transient database connectivity problem. It could display a user friendly error message rather than showing a generic error message etc: try { taskService.getOutcomes } catch(TaskDoesNotExistException e) { // Show error message: The task you tried to access does not exist } catch(Exception e) { // Show error message: Something went wrong in the workflow!! } The same approach for process instances, executions, variables, etc. could be used to allow building robust client code. was: Currently error conditions are signaled using a single exception type, JbpmException. Using problem specific exception subclasses would make it possible for the client code to deal with different error conditions differently . Example - current GetOutcomes command implementation: package org.jbpm.pvm.internal.cmd; ... public class GetOutcomes implements Command<Set<String>> { ... public Set<String> execute(Environment environment) { DbSession dbSession = environment.get(DbSession.class); TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId)); if (task==null) { throw new JbpmException("task "+taskId+" doesn't exist"); } ... Introducing problem specific exception subclasses would allow client code to handle errors much better; for example if a custom TaskDoesNotExistException (public class TaskDoesNotExistException extends JbpmException) was thrown in GetOutcomes.execute when a task is not found, then the caller code would be able to distinguish this problem from say a transient database connectivity problem. It could display a user friendly error message rather than showing a generic error message etc: public Set<String> execute(Environment environment) { DbSession dbSession = environment.get(DbSession.class); TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId)); if (task==null) { throw new TaskDoesNotExistException("task "+taskId+" doesn't exist"); } The same approach for process instances, executions, variables, etc. could be used to allow building robust client code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBPM-2682?page=com.atlassian.jira.plug... ] Peter Horvath updated JBPM-2682: -------------------------------- Description: Currently error conditions are signaled using a single exception type, JbpmException. Using problem specific exception subclasses would make it possible for the client code to deal with different error conditions differently . Example - current GetOutcomes command implementation: package org.jbpm.pvm.internal.cmd; ... public class GetOutcomes implements Command<Set<String>> { ... public Set<String> execute(Environment environment) { DbSession dbSession = environment.get(DbSession.class); TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId)); if (task==null) { throw new JbpmException("task "+taskId+" doesn't exist"); } ... Introducing problem specific exception subclasses would allow client code to handle errors much better: public Set<String> execute(Environment environment) { DbSession dbSession = environment.get(DbSession.class); TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId)); if (task==null) { throw new TaskDoesNotExistException("task "+taskId+" doesn't exist"); } for example if a custom TaskDoesNotExistException (public class TaskDoesNotExistException extends JbpmException) was thrown in GetOutcomes.execute when a task is not found, then the caller code would be able to distinguish this problem from say a transient database connectivity problem. It could display a user friendly error message rather than showing a generic error message etc: try { //... Set<String> outcomes = taskService.getOutcomes() //... } catch(TaskDoesNotExistException e) { // Show error message: The task you tried to access does not exist } catch(JbpmException e) { // Show error message: Something went wrong in the workflow!! } The same approach for process instances, executions, variables, etc. could be used to allow building robust client code. was: Currently error conditions are signaled using a single exception type, JbpmException. Using problem specific exception subclasses would make it possible for the client code to deal with different error conditions differently . Example - current GetOutcomes command implementation: package org.jbpm.pvm.internal.cmd; ... public class GetOutcomes implements Command<Set<String>> { ... public Set<String> execute(Environment environment) { DbSession dbSession = environment.get(DbSession.class); TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId)); if (task==null) { throw new JbpmException("task "+taskId+" doesn't exist"); } ... Introducing problem specific exception subclasses would allow client code to handle errors much better: public Set<String> execute(Environment environment) { DbSession dbSession = environment.get(DbSession.class); TaskImpl task = dbSession.get(TaskImpl.class, Long.parseLong(taskId)); if (task==null) { throw new TaskDoesNotExistException("task "+taskId+" doesn't exist"); } for example if a custom TaskDoesNotExistException (public class TaskDoesNotExistException extends JbpmException) was thrown in GetOutcomes.execute when a task is not found, then the caller code would be able to distinguish this problem from say a transient database connectivity problem. It could display a user friendly error message rather than showing a generic error message etc: try { //... Set<String> ourcomes = taskService.getOutcomes() //... } catch(TaskDoesNotExistException e) { // Show error message: The task you tried to access does not exist } catch(JbpmException e) { // Show error message: Something went wrong in the workflow!! } The same approach for process instances, executions, variables, etc. could be used to allow building robust client code. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira