Or a suppressed exception.
Mike
On Feb 25 2014, at 06:14 , Roger Riggs wrote:
> In some cases, I would expect that the exception being overridden
> would/should become the 'cause' of the new exception so it is not cleared
> but chained. Does JNI support that?
>
> On the original issue, discar
In some cases, I would expect that the exception being overridden
would/should become the 'cause' of the new exception so it is not cleared
but chained. Does JNI support that?
On the original issue, discarding of exceptions should be explicit not
implicit.
Keep (or insert) the exceptionClear()
On 25/02/14 11:26, Petr Pchelko wrote:
Hello, Alan.
I can see how this might be attractive but doesn't it mean you are suppressing
an important exception?
In case we’ve already got into the JNU_Throw we will throw a new exception and
override the original one anyway. However I agree that t
Hello, Alan.
> I can see how this might be attractive but doesn't it mean you are
> suppressing an important exception?
In case we’ve already got into the JNU_Throw we will throw a new exception and
override the original one anyway. However I agree that this might suppress the
warning for the c
On 25/02/2014 10:31, Petr Pchelko wrote:
Hello, Core and AWT teams.
In AWT we have a lot of pending exception warnings which are now being fixed. A
big fraction of this warnings is about a pending JNI exception at a call to
JNU_Throw*.
Why don’t we add an env->ExceptionClear() call in the begi
Hello, Core and AWT teams.
In AWT we have a lot of pending exception warnings which are now being fixed. A
big fraction of this warnings is about a pending JNI exception at a call to
JNU_Throw*.
Why don’t we add an env->ExceptionClear() call in the beginning of each
JNU_Throw function? It is ab
