I don't know at this level if it is survivable or not. The native
contract is to call that function, if I can't then I'll just throw an
exception. If it is handled as survivable in the Java code then fine,
otherwise it will cause a sane termination.
It is survivable, in this case it's possible to proceed to this code
(see XGraphicsConfiguration.java):
long cmap = x11.XCreateColormap(
dev.display,
rootWindow,
vis.lock(),
X11Defs.AllocNone
);
We need to wrap the xmu call into try/catch and set the status
variable to zero in the catch block. I can make a patch for
XGraphicsConfiguration.
On 11/27/06, Tim Ellison <[EMAIL PROTECTED]> wrote:
Geir Magnusson Jr. wrote:
> Tim Ellison wrote:
>> Oleg Khaschansky wrote:
>>> Do you suggest to introduce the error handling for all the wrappers or
>>> only for this one? If for all, do you think if it will affect the
>>> performance?
>>
>> I was thinking of something like this. In the non-error case it would
>> add an additional NULL check as the function address is being cached,
>> and no additional overhead after the cache has been populated.
>>
>> The actual exception thrown is open to debate.\
>
> :)
>
> I don't understand the context - in the event of this fault, is it time
> to simply shut down? Or is this survivable? My understanding is that
> you just don't want to see a GPF.
I don't know at this level if it is survivable or not. The native
contract is to call that function, if I can't then I'll just throw an
exception. If it is handled as survivable in the Java code then fine,
otherwise it will cause a sane termination.
> Either way, how about a hint - like "missing libxmu" or similar?
I don't know the cause, so the exception will just describe the effect.
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
