If you are looking for the decompiler itself, visit https://github.com/jindrapetrik/jpexs-decompiler
NEW : You can now close your own issues and reopen them later if needed. You can also comment closed issues.
List of issues#2743 Better handling of 'java.lang.reflect.InvocationTargetException' Exceptions
Author:
coder0107git
coder0107gitDate created:
Type: feature
Visibility: Everybody
Assigned to:
Labels: GUI
State: closed 

I was going through some old issues in one of my repos and came across [this][^1] issue.
When I was looking through it I noticed two things that could be improved in FFDec. The
first is in 'com.jpexs.decompiler.flash.gui.View.textComponentModelToView'. The code is as
follows:
```java
public static Rectangle2D textComponentModelToView(JTextComponent editor, int pos)
throws BadLocationException {
try {
return (Rectangle2D) JTextComponent.class.getDeclaredMethod("modelToView2D",
int.class).invoke(editor, pos);
} catch (NoSuchMethodException | SecurityException | IllegalAccessException |
InvocationTargetException ex) {
//method does not exist, we must be on Java8
}
//Try older method
try {
return (Rectangle) JTextComponent.class.getDeclaredMethod("modelToView",
int.class).invoke(editor, pos);
} catch (NoSuchMethodException | SecurityException | IllegalAccessException |
InvocationTargetException ex) {
Logger.getLogger(View.class.getName()).log(Level.SEVERE, null, ex);
return null;
}
```
What I was noticing is that it declares that it might throw a 'BadLocationException', but
it never actually will. Since 'modelToView' and 'modelToView2D' are both called with
reflection, any errors that occur while calling it are swallowed by an
'InvocationTargetException'. The first time this error may be encountered it just discards
the error and moves on. The second time it encounters an 'InvocationTargetException', it
logs it to the logger. This ends up meaning that when a bad location is passed in on JREs
9+, will twice as much work will be done, and redundantly at that. The first improvement I
think that could be made is to detect when an 'InvocationTargetException' is wrapped
around a 'BadLocationException' and then rethrow the underlying 'BadLocationException'
exception. I think this could maybe be done with something like
'InvocationTargetException.getCause() instanceof BadLocationException' or something
similar to detect this.
The second thing that I think could be improved is the logging of
'InvocationTargetException's. Throughout the rest of the code base there are other places
where these same exceptions are passed directly to the logger. Instead of having to go
through and refactor all instances involving 'InvocationTargetException', instead a
utility wrapper class or method around the current logger could be implemented which can
unwind 'InvocationTargetException's when they are detected.
[^1]: https://github.com/coder0107git/cheerpj-jpexs-ffdec/issues/2
In nightly 3539, I am logging the cause of InvocationTargetException in most cases and
also raising BadLocationException on this place.
State: new→upgraded
Thank you!
State: upgraded→closed
