well, that post is far from complete. Most of the method is referencing Objects that are not explainable by looking at the method. Also we have no idea from where and how that mwthod is called. Is it called frequently from somewhere?
You got two things a miss here. Fiirst GUI handling, which should not cause a crash (unless the method is called very often), but would possibly make slow GUI. Also the while loop is way insecure, unless every input is sure to end up with "sread" at a point.
fist the gui part...
What is clear, that you are handling GUI elements in that method. Now all GUI in regards to Swing is handled through AWTEventdispatchThread. when handling GUI through method such as what you posted, what you should do, is make sure, that you are dealing with the said AWT thread.
Code:
if(!SwingUtilities.isEventDispatchThread()){
SwingUtilities.invokeLater(new Runnable(){
public void run(){
//call which ever method this is.
}
});
//make sure you dont end up doing the method again.
return;
}
The above code is one one way of making sure, sure, sure, that Gui is handled through AWT thread. It creates a new runnable, which AWT thread will take responsibility of at its earliest inconvinience.
I dont know if that helps, since the problem is not quite visible, but still that is a healthy approach. It is public method anyway.
the loop part...
Code:
while(true){
String line=bfr.readLine();
if(line.equals("sread"))break;
String names=bfr.readLine();
this.h.addName(line, names);
r.addElement(line);
}
You have a while(true) loop, where the only exit possibility is behing String.equals(...), now you can think of a million possibilities when that loop never ends, right? That is very dangerous loop.
Conside this. Even if your input to the loop was correct. You read one line to check if the line equals "shread". Then you read another, make figure out names out of that... what if that line was "shread"? You would be soooo likely to have never ending loops, depending on how many lines the input happens to have, way unsafe. Dont try this at home!
You probably have a sensible method, addName(...) which simply returns when names param is null? Now the reader has no issue with reading a null line. While you dont make an issue out of it, you have an eternal loop if the end pointer "shread" was skipped. One good thing about Scanner class, is that also throws a NoSuchElementException, when the read in input returns null.
Consider chancing that to while(bfr.hasNextLine()), for example. Something that makes sure, that the loop ends.
