Closed lars-sh closed 6 years ago
There are many ways we could do this. The status quo will always wrap an exception in a ReflectException
. Your option could work just as well, but I don't see a compelling enough advantage right now to change the behaviour incompatibly.
Sure, compatibility is a point. I just wonder what developers might expect from the API.
At least for me it's the expectation, that Reflect.on(Example.class).create().get()
works mostly the same way new Example()
does - except, that reflection is used to achieve things. ReflectException
is what I expect once there's a problem with reflection stuff.
@lars-sh I would expect a third party reflection API to work like the JDK reflection API, i.e. to throw their own exceptions. Look at your sample code. You didn't catch the NPE, but a InvocationTargetException
.
Again, there are many ways to do things. I don't really disagree with your approach, but the ship has sailed for jOOR, unless there are very compelling reasons to change the current behaviour.
Expected behavior and actual behavior:
When calling a constructor or method, which is throwing an Exception, I'd expect that exception to be thrown as is - that's at least what I expect from a fluent API.
Steps to reproduce the problem:
Suggested change
Handling the InvocationTargetException and rethrowing its cause at below positions should handle things as described.
Versions: