Re: Breaking from the middle of a loop (C++)
kwikius wrote:
On Jan 30, 8:35 pm, Gianni Mariani <gi4nos...@mariani.ws> wrote:
kwikius wrote:
.....
Actually IMO in this situation it is best to throw an exception at the
point the invalid command is detected.
There is no need for speed on unintelligable command, and is more
robust than relying on manually doing the check :
char validUserCommand()
{
for( ;; ) {
try{
std::string const line
= ValidCommandStringFromUser();
return line[..];
}
catch( InvalidCommandStringFromUser & e){
doShortHelpOnCommands();
continue;
}
}
}
NO NO.
YES YES YES :-)
It's not easier to read.
It's not more efficient.
How long will it take the user to figure out why their input is
invalid? Who needs microsecond efficiency here?
Note that the alternative is to manually check the data after its
arrived. Problem is that you have to remember the check. If you
"forget" the check then the function returns invalid data as if
nothing happened.
With the exception approach, if you dont catch then an error will be
transmitted . It may be ugly but it will not be missed. IOW its better
if missed error handling smacks the programmer in the face, not the
user.
If you take that argument, all return values should be exceptions.
From my experience, C++ exceptions are too inflexible, don't work well
with threads (and most libraries today need to work with threads) and
code that does not use exceptions, is easier to understand. Also, most
compilers/debuggers don't support debugging of exception conditions very
well.
I have yet to a good prolific use of exceptions in an application. The
rule that seems to work for me is that exceptions are "exceptional" and
so should only be used in "exceptional" circumstances.
For example:
matrix a, b;
....
matrix c = a/b;
in this case, b may be a singular matrix and a/b may not result in a
usable value for c. I have no issue with that code throwing an
exception - but - it had better be managed and this is where C++ breaks.
There is no compile time check that it is handled and there should be.
Input into the program must be anything and so it's not an "exception"al
thing to detect bad input.
I've tried writing code where exceptions are used more liberally and
they only make sense where the lower levels of code don't usually deal
with the problems
In this case you have asked user for input. If you can't understand
the input you get - don't proceed.
In this case, the code simply asks again, and again if it does not
understand input. Having exceptions handle this makes code less
readable and hence more prone to making errors.