I've got a candidate for a code of the month here:
I've got a candidate for a code of the month here:
// is it a number?
try
StrToInt(SomeEditText);
IsNumber := True;
except
isNumber := False;
end;
Using exception for conditioning - that's a design pattern out of this planet!
// is it a number?
try
StrToInt(SomeEditText);
IsNumber := True;
except
isNumber := False;
end;
Using exception for conditioning - that's a design pattern out of this planet!
Daniela Osterhagen IIRC in java, you are forced to use try-catch for methods(or was it classes?) that can throw exceptions, basically the compiler refuses to spit the byte codes
ReplyDeleteDaniela Osterhagen You mean common anti-pattern based on faulty assumptions. http://stackoverflow.com/questions/299068/how-slow-are-java-exceptions
ReplyDeleteIt's not a matter of which is faster (exceptions rarely ever are regardless of language) but a matter of correctness. Take a look at this stellar example:
try
i := 0;
while True do
begin
items[i] := i;
Inc(i);
end;
except
end;
This is, of course, a straw man example. Why anyone would actually do this on purpose is beyond me. I hope no one reading this ever considers this to be a good idea but I think it gets the point across. First this code will only work correctly if you have range checking turned on. Second, it obfuscates what is actually being done. Finally, it takes at least twice as long to complete as using a for loop.
Btw, I took that example from Effective Java by Joshua Bloch.
Using exception to do the flow control is not suggested, man..
ReplyDelete