using exceptions to check if entry was valid

So im writing a program that converts a seven digit phone number to all the possible words that correspond. In error checking, it rejects (and has the user type in another number) that does not contain 1 or 0, or that contains anything other than digits. Is it possible/easier to use exceptions?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
 //Phone.cpp

#include <iostream>
#include <string>
#include "Phone.h"

using namespace std;

Phone::Phone(string _phoneNum)
{
	setPhoneNum(_phoneNum);
}

void Phone::setPhoneNum(string _phoneNum)
{
	//checks format of given number
	//checks every character
	num_is_digit = true;		//every char is a digit by default
	one_or_zero = false;		//no digits are 1 or 0 by default
	for (int i = 0; i < _phoneNum.length; ++i)
	{
		//if number contains anything other than digits
		if (!isdigit(_phoneNum[i]))
		{
			num_is_digit = false;	//reject number given by user
			break;
		}
		//if number has 0 or 1
		if (_phoneNum[i] == '1' || _phoneNum[i] == '0')
		{
			one_or_zero = true;
			break;
		}
	}
	//if number is not valid, try again
	if (!num_is_digit || one_or_zero)
		enterAnotherNumber();
	else
		phoneNum = _phoneNum;
}

string Phone::getPhoneNum() const
{
	return phoneNum;
}

void Phone::enterAnotherNumber()
{
	cout << "Error: Number is not valid\nEnter a seven digit number, omit 1 or 0\n";
	getline(cin, phoneNum);
	setPhoneNum(phoneNum);
}
1. Your code rejects any string that contains '0' or '1', not any string that doesn't contain '0' or '1'.
2. Your program may recurse infinitely. Try to restructure your code to avoid this situation.
3. Regarding your original question, IMO exceptions are not the way to go here.
1. I meant it rejects any string that contains '0' or '1', so the code is what i want.
2. I will try to avoid infinite recursion.

Thanks!
setPhoneNum is doing too many things: it validates the number, stores the number and prompts the user for a different number if it isn't valid. If you had to change the program to scan a a file of numbers and print out the invalid ones, you'd have to change a lot.

A function should do just one thing. change setPhoneNum to bool isValidPhoneNum(const string &number). Then somewhere your code will do something like:
1
2
3
4
while (!isvalidPhoneNum(num)) {
    enterAnotherNumber(num);
}
phoneNum = num;

gotcha that makes sense. So I assume I would validate the number first, then when it's validated correctly, move on to setPhoneNum

Thanks a bunch.
Once you have isValidPhoneNum() and enterAnotherNumber(), what is left for setPhoneNum() to do except assign the phoneNum member? That's why I just assigned phoneNum = num at line 4 in my comment. It seems to me that you don't need setPhoneNum() at all.

I should say that I'm not a fan of accessor methods that simply get and set member variables. Although they have their place and I've written them, I usually start from the assumption that I DON'T need them.
Yea I saw that I didnt need the set accessor method for that one line of code. What about the get method? I understand that it does serve a good purpose with encapsulation.
Like I said, get() and set() methods serve a purpose, but they are frequently misused. They are useful if get/set does more than just return the variable, or if you are writing a library that will have many many users who won't want to change their code if you change your data representation, and if there is some chance that you actually WILL change the data representation, and if your users can tolerate the recompile that a change in data representation will require if the size changes....

If you use get/set methods to access your data, then you give up:
- taking the data's address
- creating a reference to it
- ++ and --
- +=, -=, etc.

My advice: start with the assumption that you should NOT use accessor methods and then think of reasons why they might be helpful. If you can, then use them. I know I have. But if not, stick with public data members.

I'm saying this with 35 years of programming experience, 26 of which have been in C++.
Very good advice. Thanks!
Topic archived. No new replies allowed.