Trace:
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
jvx:client:gui:exceptionhandling [2018/02/01 22:07] admin created |
jvx:client:gui:exceptionhandling [2020/07/08 17:36] (current) cduncan articles |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | ~~Title: Exception handling~~ | + | ~~NOTRANS~~ |
| + | ~~Title: Exception Handling~~ | ||
| - | Exception handling is very important for applications. It's necessary to visualize unexpected exceptions and to handle expected exceptions. But exception handling should be easy, centralized and shouldn't blow up the application code. Isn't it boring to catch Exceptions after unimportant code blocks? | + | Exception handling is very important for applications. It's necessary to visualize unexpected exceptions and to handle expected exceptions. Exception handling should be easy, centralized, and shouldn't blow up the application code. Isn't it boring to catch exceptions after unimportant code blocks? |
| - | This could be boiler-plate code: | + | This could be boilerplate code: |
| <file java> | <file java> | ||
| Line 18: | Line 19: | ||
| </file> | </file> | ||
| - | If you catch Exceptions to show error messages, it's boiler-plate code. If you catch exceptions to do specific error handling, it's not. Usually an application has both use-cases. | + | If you catch exceptions to show error messages, it's boilerplate code. If you catch exceptions to do specific error handling, it's not. Usually an application has both use-cases. |
| With JVx, we tried to reduce code for exception handling to a bare minimum. We delegate "all" framework exceptions to an ExceptionHandler. The ExceptionHandle is more or less a delegator. | With JVx, we tried to reduce code for exception handling to a bare minimum. We delegate "all" framework exceptions to an ExceptionHandler. The ExceptionHandle is more or less a delegator. | ||
| - | The ExceptionHandler doesn't visualize an exception. It forwards exceptions to a listener list and is responsible for logging. The application itself is reponsible for visualization because only the application knows how to visualize an exception - as Popup, as status in a specific area, ... | + | The ExceptionHandler doesn't visualize an exception. It forwards exceptions to a listener list and is responsible for logging. The application itself is responsible for visualization because only the application knows how to visualize an exception - as a popup, as a status in a specific area, etc. |
| The standard JVx application already supports visualization of exceptions because it's a registered exception listener. The method | The standard JVx application already supports visualization of exceptions because it's a registered exception listener. The method | ||
| Line 55: | Line 56: | ||
| </file> | </file> | ||
| - | will do the job. Simply override the method to do what you want or register your own listener and remove the application ans exception listener. | + | will do the job. Simply override the method to do what you want or register your own listener and remove the application and exception listener. |
| - | The default implementation makes is super easy to show exceptions without additional code. Suppose we have following action: | + | The default implementation makes it super easy to show exceptions without additional code. Suppose we have the following action: |
| <file java> | <file java> | ||
| Line 69: | Line 70: | ||
| </file> | </file> | ||
| - | The callAction method will throw Throwable because it's a remote procedure call and all remote procedure calls will throw Throwable instead of an Exception. JVx doesn't define custom exceptions because Java has enough and it wasn't necessary to wrap exceptions for remote calls. The application is able to define custom exceptions in remote procedure calls, but JVx doesn't wrap exceptions. It's nice for an application developer to get the thrown exception instead of unwrapping a catched exception to get the original exception. | + | The callAction method will throw throwable because it's a remote procedure call and all remote procedure calls will throw throwable instead of an exception. JVx doesn't define custom exceptions because Java has enough, and it wasn't necessary to wrap exceptions for remote calls. The application is able to define custom exceptions in remote procedure calls, but JVx doesn't wrap exceptions. It's nice for an application developer to get the thrown exception instead of unwrapping a caught exception to get the original exception. |
| - | To make our action working, we could do following: | + | To make our action working, we could do the following: |
| <file java> | <file java> | ||
| Line 80: | Line 81: | ||
| </file> | </file> | ||
| - | It's good enough to add throws Throwable to the method definition. The event mechanism of JVx will do the rest, because it forwards exceptions to ExceptionHandler: | + | It's good enough to add throws throwable to the method definition. The event mechanism of JVx will do the rest because it forwards exceptions to ExceptionHandler: |
| <file java> | <file java> | ||
| Line 114: | Line 115: | ||
| </file> | </file> | ||
| - | This will handle MessagingException and all other exceptions will be handled from the default implementation. But it's also possible to ignore the default implementation: | + | This will handle MessagingException and all other exceptions will be handled from the default implementation. It's also possible to ignore the default implementation: |
| <file java> | <file java> | ||
| Line 164: | Line 165: | ||
| </file> | </file> | ||
| - | The raise method will interrupt code execution and show will continue. | + | The raise method will interrupt code execution while show will continue. |
| - | The ExceptionHandler knows one specific Exception which will be handled separately. It's the SilentAbortException. If you throw a SilentAbortException, no listener will be notified about the exception. This also means that your application doesn't visualize the exception. | + | The ExceptionHandler knows one specific exception which will be handled separately. It's the SilentAbortException. If you throw a SilentAbortException, no listener will be notified about the exception. This also means that your application doesn't visualize the exception. |