JPEXS Free Flash Decompiler Issue Tracker

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 issuesList of issues

#2743 Better handling of 'java.lang.reflect.InvocationTargetException' Exceptions
Date created:
Type: feature
Visibility: Everybody
Assigned to:
Labels: GUI
State: closed Help

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