K
kavithadayalanvit
i want to search a particular word in the file using java.
can u give any specific link for this
regards
kavitha
can u give any specific link for this
regards
kavitha
L
Luc The Perverse
Read the file
Check the input for the word
If the word is found then display something
Repeat.
. . . .
Maybe it would be better if you showed us what you had tried, specifically
what is not working and we can work from there.
L
Lab.Bhattacharjee
Hi kavitha,
u can try out the following code , it allows wild cards ,but is case
sensitive.Please tell me if u need that too??
import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class RnD {
public static void main(String[] args) {
Pattern pattern = Pattern.compile("SAXELBY");
BufferedReader reader = null;
try {
int lineNumber=0;
reader =
new BufferedReader(
new FileReader("C:\\00000001.txt"));
while (true) {
lineNumber++;
String curline = reader.readLine();
if (curline == null) {
break;
}
Matcher matcher = pattern.matcher(curline);
while (matcher.find()) {
System.out.println("at "+lineNumber+" "+
matcher.group()
+ " start="
+ matcher.start()
+ " end= "
+ matcher.end());
}
}
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} finally {
if (reader != null) {
try {
reader.close();
} catch (IOException e1) {
e1.printStackTrace();
}
}
}
}
}
thanks
lab
u can try out the following code , it allows wild cards ,but is case
sensitive.Please tell me if u need that too??
import java.io.BufferedReader;
import java.io.FileNotFoundException;
import java.io.FileReader;
import java.io.IOException;
import java.util.regex.Matcher;
import java.util.regex.Pattern;
public class RnD {
public static void main(String[] args) {
Pattern pattern = Pattern.compile("SAXELBY");
BufferedReader reader = null;
try {
int lineNumber=0;
reader =
new BufferedReader(
new FileReader("C:\\00000001.txt"));
while (true) {
lineNumber++;
String curline = reader.readLine();
if (curline == null) {
break;
}
Matcher matcher = pattern.matcher(curline);
while (matcher.find()) {
System.out.println("at "+lineNumber+" "+
matcher.group()
+ " start="
+ matcher.start()
+ " end= "
+ matcher.end());
}
}
} catch (FileNotFoundException e) {
e.printStackTrace();
} catch (IOException e) {
e.printStackTrace();
} finally {
if (reader != null) {
try {
reader.close();
} catch (IOException e1) {
e1.printStackTrace();
}
}
}
}
}
thanks
lab
L
Lew
The word is "you", not "u".
The trouble with doing someone's homework for them is that you deprive them of
an education. That's a big waste of their tuition.
Please do not embed TABs in Usenet posts.
What is this regex? How did you come up with it? There was no indication in
the OP for this.
Hard-coded strings. Tsk, tsk. Where did you come up with it? There was no
indication in the OP for this.
To depend on exceptions as flow control is a bad practice.
Ooh, you ignore the exception and move on. This is good for examples, bad in
practice.
This is also a good place to introduce logging statements.
Those darn TABs.
- Lew
O
Oliver Wong
R
Randolf Richardson
[sNip]
This typically occurs because the reserved word "goto" isn't
implemented. There are situations where "goto" would be very useful, such
as:
0. An alternative to "break label" since label is currently limited in
where it can be located (such code could be easier to read)
1. The ability to share code between methods within a class, which all
end with the same functionality (this could be more efficient than calling
another method; javac would need to generate errors such as attempts to
access variables that belong to different methods, return type mismatches,
etc.)
I do agree with your view that infinite loops that depend on exceptions
are a bad practice. Using conditionals to trigger a "break" would also be
better handled by making that the focus of the loop -- and if they need to
compare afterwards, then "do { ... } while (condition);" can certainly
solve that problem.
K
kavithadayalanvit
hi
thanks for ur reply. it will also be helpful if u sent the coding
which u have asked me .
waiting for ur reply
regards
D.kavitha
G
Gordon Beaton
That may be, but he hasn't done so in this case. The loop condition
here is (curline != null), even though the test doesn't occur until a
few lines further down.
BTW exceptions *are* a form of flow control, whether you like them or
not.
/gordon
M
Michael Rauscher
Gordon said:
That may be but he didn't tell us if they are or are not a form of
control flow.
To my understanding the key was not to *depend* on exceptions as flow
control or IOW not to (mis)use the exceptional flow to control the main
flow which is right although not always possible.
Bye
Michael
L
Lew
Juat a word of friendly advice: Your posts will seem much more professional,
and you will be in better practice for workplace communication, if you make a
habit of using more (not completely) formal written English, in particular if
you avoid so-called "l33t-speak" or "txt-English", comprising abbreviations
like "u" for "you", informal or missing punctuation and capitalization, etc.
The trouble is that the use of the abbreviated idiom conveys an impression of
unprofessionalism and a low skill set. This may be the view of yourself that
you wish to convey, but I fail to see how that can help you.
You will impress more, and likely get more expert responses, if you take the
care and trouble to follow conventional English syntax and orthography
(barring the odd misplet word - this forum isn't completely formal).
Just a suggestion designed to help you.
- Lew
T
Tor Iver Wilhelmsen
Randolf Richardson said:
That's headache-inducing and makes the code far less readable (thus it
runs counter to your item 0). Why do you think the MINISCULE overhead
in a local method call is worth the MAJOR hassle of having to look in
so many places to follow the flow of a method? Not to mention that you
still would only be able to goto code that completes with a return,
and the label's method would need to have the same return type and
with a compatible throws clause, and the class file spec would need to
add a global label table...
Refactor the shared code into a private final method and trust the
runtime to inline the code as necessary. Or wait for closures to be
implemented.
M
Martin Gregorie
I totally disagree. Assemblers need "goto" but no decent HLL does. ThatRandolf said:
goes for COBOL too and before you ask, yes I've written GOTO-less COBOL.
I have never used goto (or needed it) in C and see no need for it in Java.
I don't use this construction in C either and, again, don't need it.
Encapsulating the code in a private method makes for more readable code
as well as eliminating code duplication.
Yes - but that's a result of classes that throw exceptions when their
methods would be better off returning control values. IMO if you have to
use exceptions to control normal logic flow in code that calls the class
methods merely demonstrates bad class design.
I never design classes/methods that force their user to control normal
logic flow with exceptions: I use methods that return control
information (e.g hasNextObject() to control loops). Similarly, my
constructors never throw exceptions: code that may signal errors with
exceptions is pulled out of the constructor and encapsulated as a
separate method. This is because try...catch blocks that include class
instance declarations screw up otherwise clean block structures by
preventing me from grouping all object instance declarations at the
start of a block rather than sprinkling them through the code.
R
Robert Klemme
Adding to that: a meaningful subject also often helps.
Cheers
robert
A
Alex Hunsley
Randolf said:
I disagree, I think goto was dumped for very good reasons, and
structured programming (i.e. no gotos; use methods and refactoring
techniques instead) makes a lot more sense.
R
Robert Klemme
Completely agree, Martin. "Goto" is quite nonsense - it's not needed
from a theoretical as well as from a practical point of view.
Plus, with modern JVM's the private method is typically inlined *if* it
is a performance bottleneck. If not, it's not worth bothering about the
method invocation overhead anyway.
Side note: I am amazed that the "issue" of "goto" keeps popping up. The
high time of Basic has long since gone but people still seem to cling to
this ancient concept. Or do all these folks use assembler during their
daily work?
Regards
robert
L
Lew
Martin said:
Personally I prefer to declare variables closest to the point of use, rather
than all at the beginning of a block.
- Lew
J
John W. Kennedy
Alex said:
I suspect that Java left in "goto" as a reserved word for the same
reason that Ada supports (with intentionally hideous syntax) "goto" --
considerations of machine-generated code.
But jumping from one method to another? Ye gods! Even Fortran doesn't
allow that, except for a jump-out-to-caller mechanism that is
essentially a poor-man's "throw".
R
Randolf Richardson
That's a perfectly valid alternative for one particular application of
"goto."
This discussion is very interesting. One of the reasons I think "goto"
keeps coming up is that there is demand for it. Although it is commonly
associated with BASIC, it's also available in other languages such as Perl
(which can be written in a procedural or OO style, or as mixture of both),
assembler (the instruction is usually called "jmp"), etc.
I'm not convinced that "goto" is a bad thing, especially given the
numerous "while (true) { ... }" loops that I've seen over the years
(granted, those are usually examples of bad coding style, but many people
use it because they don't have "goto" at their disposal).
To me, the limit on the placement of labels at the beginning of a loop,
followed by a partial "goto" using the "break label;" instruction is
actually more difficult to follow because first one has to find the label
in preceeding code, then search for the end of the loop to follow the
program flow from there. If the label could at least be placed anywhere
from the beginning of the loop to immediately after its end, with "goto"
enabled for this, I do think this could actually make things a bit better.
I definitely don't agree that removing "goto" eliminates "spaghetti code"
and works against the OO concept (as someone pointed out in a separate
reply), rather it's the individual developers who will continue to write
terrible code even without "goto" (which seems to happen now). As an
aside, a much more serious problem is the lack of source code comments
(usually the majority of the comments in source code are a copy of the GPL
or some other license agreement -- the slightly better programmers include
a minor smattering of vague hints in what seem to be fewer than one or two
dozen randomly selected lines {out of thousands}).
I do believe that a good developer can use "goto" in an intelligent way
that doesn't result in "spaghetti code" and doesn't detract from the OO
concept, so perhaps if Sun ever does decide to implement it they could
also require a "javac" command-line option like
"-allowadvancedinstructions:goto" as a hint that alternatives are strongly
encouraged.
The masses seem to be convinced that "goto" is bad, but in the history of
the world there are countless examples where the masses were wrong (e.g.,
political elections, setting women on fire to determine if they were
witches, removing tonsils because medical experts at the time believed
them to be useless, mis-treatment of leppers, etc.).
M
Martin Gregorie
Yes, I know your preference is normal and widely used.Lew said:
That was a personal opinion intended to show why I don't like
constructors that throw exceptions. I've written far too much C (and
Algol 60, Algol 68R, PL/9 and PL/1) to easily let go of the habit of
declaring variables at the start of a block. If that makes me weird, so
be it.
R
Robert Klemme
I'm guessing that the demand is rather low - compared with the demand
for other things (including fixing bugs).
An endless loop with "while(true)" is at least as good as a loop with
"goto".
We must have very different coding styles. I cannot remember ever
having used a label in Java. I simply don't need them.
You are right. But this does not make an argument for introducing
"goto" in Java. Only if benefits outweigh costs of this change it's
reasonable to do it. And I don't see that.
I won't follow this train of discussion as there are numerous things
that could be said to this. Just this: if the majority of people do not
care to have "goto" in Java then Sun's efforts are spent far better in
realizing other features or fixing bugs. This alone is reason enough
for not doing it IMHO.
Regards
robert