Discussions

News: Introducing JEHA, the Java Exception Handler framework

  1. The Jeha framework has released version 1.0. The main idea of Jeha is to make easy exception handling process, using simple concepts as annotations and Handlers. You can annotate your methods/classes and don´t need to worry about handling details anymore. Only few steps are enough to make it works: 1) Create your handler: public class MyHandler implements Handler {    public Throwable handle(Throwable throwable, Object... params) {       System.out.println("Handing...");    } } 2) Annotate your class: public class Test {    @ExceptionHandler(MyHandler.class)    public void methodA() {       // some code here    } } 3) Use Jeha´s Maven plugin for glue everything:    org.codecompany    jeha-plugin    1.0                     process-classes                       jeha                      That’s it! Now every time an exception is raised from Test.methodA(), Your handler will capture it and execute MyHandler.handler() method. There are many other features that make Jeha very easy to learn and use. Look at the quick start guide and see how productive you could be. Jeha is licensed under Apache License 2.0. You download the framework including a quick start guide, full source code and examples here: http://sourceforge.net/projects/jeha/

    Threaded Messages (28)

  2. 2 cents...[ Go to top ]

    Sounds interesting. I'm curious though, if the handler needs to analyze the private internals of the object for recovery or error messages, how would you do this?
  3. You can pass any parameters to handler's method (including current object). So, the handler will be aware of the context he is executing. By default Jeha passes only methods' parameters to Handler. If you need something more advanced you can write a call to HandlerUtil.handle() manually, as explained in start guide. Andre
  4. Good point.[ Go to top ]

    What problem this framework is trying to solve?

    Good point. This sample would be a good case where to demonstrate the usefulness of closures. /Oliver
  5. looks similar to EXCHA[ Go to top ]

    Looks similar to EXCHA to me. http://excha.sourceforge.net/ however EXCHA has got out of the box: retries, exception substitution, integration with spring, logging.
  6. Re: looks similar to EXCHA[ Go to top ]

    This looks even worse. It is painfully obvious that the problem is not the language but the inability of the community to create well designed open API's and runtimes that tackle the problem domain completely devoid of the context of the instrumentation.
  7. Re: looks similar to EXCHA[ Go to top ]

    >It is painfully obvious that the problem is not the language but the inability of the community to create well designed open API's and runtimes that tackle the problem domain completely devoid of the context of the instrumentation.
    Honestly do you expect API be even simpler? ;-) @HandleThrown( logLevel = LogLevel.ERROR, logVerbosity = LogVerbosity.ARGUMENTS, retriesBeforeProcessing = 5, delayBeforeRetry = 10 * 1000) or @HandleThrown(substitute = TimeoutException.class, substituteBy = ApplicationRuntimeException.class} As for tooling EXCHA works seamlessly with Spring AOP and AspectJ. One line to configure it sprion-aop or aspectj what can be simpler?!
  8. Re: looks similar to EXCHA[ Go to top ]

    Mark you seem to completely miss the point. You should not be annotating the code with actual behavioral (implementation) concerns such as logging, retry(ing), substitution,.... You might as well write the code though I doubt any of the annotation values have any practical usage in a real-world context. You fail to see the model the underlies a comprehensive diagnostics solution: state observation (targets, parameters), execution flows (process frame, thread frame, and stack frames). You also limit the extensibility and versatility of any realization of a supporting runtime. But if you really need an annotation here are a few we offer though most of our customers just drop in a library in the extension path and that is it. // create a diagnostics (thread stack) frame representing the operation @DiagnosticPoint @DiagnosticTarget // dump observations made at process, thread, and stack frame(s) levels @DumpPoint @DumpTarget // make the object's state observable in the global diagnostics frame @ObservePoint @ObserveTarget Note: *Point annotations target individual methods, *Target annotations target all methods in a class. Nothing else need be specified.
  9. Re: looks similar to EXCHA[ Go to top ]

    State Observation: The Good (JXI), Bad (JMX), Ugly (JMX) http://williamlouth.wordpress.com/2008/07/16/the-good-jxinsight-bad-jmx-ugly-jmx/
  10. Re: looks similar to EXCHA[ Go to top ]

    You should not be annotating the code with actual behavioral (implementation) concerns such as logging, retry(ing), substitution,....
    Why shouldn't I use annotations if it helps to reduced the amount of code and improves the quality of code? btw, EXCHA reduced by half the amount of code in my service classes. Also, if you don't want use annotation you can use schema based configuration approach (but it is for spring only).
    But if you really need an annotation here are a few we offer though most of our customers just drop the library in the extension path and that is it.
    How do they specify which exception they want to substitute, which exception should force trigger method re invocation? Do you they write log.error, log.warning in each catch block?
  11. Re: looks similar to EXCHA[ Go to top ]

    How do they specify which exception they want to substitute, which exception should force trigger method re invocation?
    That is exactly the point which seems completely lost on most Java developers accustomed to reading 100 character class names that near enough spell out the implementation details of the class itself. Hint: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXBeanFactory
  12. Re: looks similar to EXCHA[ Go to top ]

    It is painfully obvious that the problem is not the language but the inability of the community to create well designed open API's and runtimes that tackle the problem domain completely devoid of the context of the instrumentation.
    You can use Jeha without any instrumentation or AOP magics, just calling HandlerUtil.handle(). Besides, you can use any variables/parameters in Handler: public class Test {    @ExceptionHandler(MyHandler.class)    public void methodA(int x, int y) {       try {          // some code here       } catch (Exception e) {          HandlerUtil.handle(e, x, y);       }    } } In above code there is no instrumentation, and the framework will only use reflection. So, I cannot agree with you about what you said.
  13. Re: looks similar to EXCHA[ Go to top ]

    Looks similar to EXCHA to me.
    I don't think so. First of all, I don´t think that something like substitution or retries must be described in annotations. Besides, an annotation as described below is so complex that become very difficult to read or maintain. Imagine a class with 10 methods! @HandleThrown( substitute = {TimeoutException.class, SomeRuntimeException1.class, SomeRuntimeException2.class, RuntimeException.class }, substituteBy = { SystemApplicationRuntimeException.class, BusinessRuntimeException.class, BusinessRuntimeException.class, SystemApplicationRuntimeException.class }, wrapCause = { false, false, false, true }, logLevel = LogLevel.ERROR, logVerbosity = {LogVerbosity.ARGUMENTS, LogVerbosity.STACK_TRACE }, retriesBeforeProcessing = 5, delayBeforeRetry = 10 * 1000) With Jeha you encapsulate your handling strategy in a Handler, what is more concise and simpler: @ExceptionHandler(MyHandler.class)
  14. Re: looks similar to EXCHA[ Go to top ]

    First of all, I don´t think that something like substitution or retries must be described in annotations. Besides, an annotation as described below is so complex that become very difficult to read or maintain. Imagine a class with 10 methods!
    Imagine you have a service with 50 methods that do same things. A GWT service, or something that works with database. You have same exception handling logic almost everyware. That means you can write one such annotation per class and customize methods that have different exception handling logic. With annotation based approach you reduce the code size sometimes twice. Also the chance of error is smaller since you do not copy paste same things in catch block. So you have either one annotation or 50 try/catch blocks. As for "AOP magic" - the framework hides it all from mere mortals. I use it with Spring and I'm not a pro in AOP at all. Besides EXCHA has custom ExceptionHandler's similar to what you provide. But honestly I never tried it because the framework does everything I need in exception handling:
  15. Logging (it can print arguments, stack trace)
  16. Substitution one exception for another
  17. Retries (I love this stuff for timeouts and transactions deadlocks)
  18. swallowing exceptions. The amazing thing is how much code can be reduced by such small project.
  • AOP[ Go to top ]

    Looks interesting, although I can't help but wonder what the value add is here over a standard AspectJ pointcut is?
  • AOP[ Go to top ]

    The idea is to save you from AspectJ syntax and runtime libraries. The weaven is done via Javassist and no AOP knowledge or library is necessary.
  • Re: AOP[ Go to top ]

    The idea is to save you from AspectJ syntax and runtime libraries.
    Sorry I am completely confused with the logic of this argument especially as you are instructing a developer to actually change (@annotate) his code creating an explicit dependency on your project. With AspectJ this can be done completely external, much more efficiently, and with the right tooling diagnostics can be productive (and fun). Our customers only have to drop in an AspectJ extension library into the runtime classpath and if they want to create a more refined extension they can by merely editing an xml file though we ship with 700+ extensions covering most of the standard and open source technologies. Java Runtime State Diagnostics http://www.jinspired.com/products/jxinsight/diagnostics.pdf By the way we have deliberately separated instrumentation from the model and tooling which allows us to support other aspect like libraries as well as explicit diagnostics calls. William
  • Re: AOP[ Go to top ]

    I think there is a misunderstanding. The main idea of Jeha is to modularize exception handling, so you can reuse your Handlers. We can discuss why I'm not using AspectJ for doing this but I don't think this is the point, since weaven process is just one strategy for placing handle() calls and it is possible can do everything without maven or Jeha's plugin. The thing that is important is that using Jeha you can separate your handling logic and reuse it. The use of annotations simplifies the understanding of code because a developer can see a method and “on the spot” he will know that any exception raised from there will be handled by a Handler X. He doesn’t need to analyze XML files or understand pointcuts.
  • Not sure about the value[ Go to top ]

    I might be missing the point - but this feels like re-introducing checked exceptions via the backdoor?! For the vast majority of calls I do only want to deal with my exceptions at the very outer level of the invocation tree. As, I assume, the handler's represent an 'around' advice they will not do this?!
  • Re: Not sure about the value[ Go to top ]

    Handler is responsible for handling the exception and it is invoked via HandlerUtil.handle(). When you use Maven plugin, all methods annotated with @ExceptionHandler will be modified. There are two points in this modification: 1) If the method has a try/catch block, a call to HandlerUtil.handle() will be inserted as first line of each catch. 2) If you prefer, the whole method could be surrounded by a try/catch and a call to HandlerUtil.handle() will be inserted in catch block. Of course you can write the code without the plugin, which is more flexible. The Handler is not a 'around advice' and it is only invoked when the exception is risen. You do not control the method flow in this case (because the exception has already been risen), but you can act to handle it. The framework idea is to separate this 'handling strategy' in a class and reuse it in many parts of your code. Based on the method Jeha can identify which Handler must be invoked when an exception occurs.
  • Re: Not sure about the value[ Go to top ]

    What kind of 'handling' do you expect to do in here? As you said the error is already thrown so I guess you won't be able to 'unthrow' it or stop it from cascading. The main use I can see would be to standardise error logging?!
  • Re: Not sure about the value[ Go to top ]

    the same kind of handling that you put in a catch block
  • What problem this framework is trying to solve? Thanks, -- Nikita Ivanov GridGain - Cloud Development Platform
  • JEHA[ Go to top ]

    Very interesting... As i see it would reduce the lines of code through the reuse of exception handling blocks and also reduce the cyclomatic dependency.
  • Re: JEHA[ Go to top ]

    I thought this was more for diagnostics than actually exception handling. I would hate to think that developers would even consider removing flow/state specific event handling out from the methods themselves. If that is the case why not just rethrow the exception itself. How many methods are really that simple (primitive) in their exception handling that they do not take into account the actual execution state within (variables, execution sequence, ....) the method itself. I suspect most handlers are just loggers which is a sad state of affairs considering how primitive and useless that is in general.
  • Re: JEHA[ Go to top ]

    +1 Kind of my sentiment too after giving it a good thinking... Cute idea but I don't think it's going to work well in the real life. My 2 cents, -- Nikita Ivanov GridGain - Cloud Development Platform
  • With AOP I don't even have to touch any of my code, i.e. no annotations I have to use. I can just simply configure context.xml for handling exceptions. Can you do the same with jeha?
  • No, that's not possible and that's not the idea of Jeha. I think that it is important to specify explicitly which Handler will handle which code, so the developer can see it clearly in the method.
  • I would say the following: With AOP you don´t have to touch any of your code, but you must do a lot of XML arounds... And i don´t think this is easier.