After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 319555 - FileChooserBut.setFilename doesn't handle null values
FileChooserBut.setFilename doesn't handle null values
Status: VERIFIED FIXED
Product: java-gnome
Classification: Bindings
Component: GTK
Really Ancient
Other Linux
: Normal normal
: ---
Assigned To: Ismael Juma
Ismael Juma
Depends on:
Blocks:
 
 
Reported: 2005-10-23 20:24 UTC by Emmanuel Rodriguez
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A patch to prevent the JVM crash (732 bytes, patch)
2005-10-23 20:27 UTC, Emmanuel Rodriguez
none Details | Review

Description Emmanuel Rodriguez 2005-10-23 20:24:56 UTC
FileChooserButton.setFilename(null) causes the JVM to crash.
Comment 1 Emmanuel Rodriguez 2005-10-23 20:27:08 UTC
Created attachment 53804 [details] [review]
A patch to prevent the JVM crash

This patch will replace a null fileName with the empty string.
Comment 2 Ismael Juma 2005-10-23 20:55:41 UTC
The current behaviour is definitely not acceptable, but I am not sure if the
proposed behaviour is the right way to go. How about the possibility of throwing
an exception?
Comment 3 Emmanuel Rodriguez 2005-10-24 05:50:34 UTC
At first I was thinking of throwing a runtime exception, but then I took a look
at Entry.setText() as a reference and I noticed that it was changing the input
parameter. Therefore, I did the same assuming that it will be the right thing.

I agree that modifying the input parameters can be tricky, in this case changing
from null to the empty string can be understood but in other cases it may not be
as trivial.

Personally I will prefer the API to be consistent. Either all methods validate
their input and throw a runtime exception (possibly the same) or have them
modify the input value in order to correct it, as it is done by Entry.setText().

I am open to all suggestions as long we can prevent the JVM from crashing and
that the errors can be trapped or prevented by java code.
Comment 4 Ismael Juma 2005-10-24 08:26:38 UTC
Unfortunately, the bindings are not very consistent. I am of the opinion that
setter methods should throw an IllegalArgumentException if they are passed null
in cases where null is not an acceptable value. In the case of Entry#setText,
the documentation does not mention if null values are acceptable, but I wonder
if people are relying on that behaviour already...
Comment 5 Emmanuel Rodriguez 2005-10-24 11:29:27 UTC
Do you mind then updating the code of FileChooserButton#setFilename with a
runtime exception or should I resubmit another patch?
Comment 6 Ismael Juma 2005-10-24 11:37:52 UTC
I can do it. Also the correct way to do this is to have the check in
FileChooserHelper so that the various FileChooser implementations can benefit
from the check. I first wanted to know if the RuntimeException was satisfactory
to you, however.
Comment 7 Emmanuel Rodriguez 2005-10-24 12:09:34 UTC
The runtime exception works for me and modifying FileChooserHelper is a great idea.
Comment 8 Ismael Juma 2005-10-24 20:15:41 UTC
Thanks for reporting this. Fixed all FileChooser implementations
(FileChooserDialog, FileChooserButton, FileChooserWidget) in CVS HEAD.