What I mean is that you are using exceptions to control the flow of your class which shouldnt be the case. You should only use exceptions when you want to throw an major error.
Infact you are doing the complete opposite of what exceptions are supposed to be doing:
Quote:
|
An exception is an event, which occurs during the execution of a program, that disrupts the normal flow of the program's instructions.
|
A very good example is the "new" keyword in c++. When you allocate memory in c++ you can wrap it in a try/catch block and catch the std::bad_alloc exception. In this case where memory can not be allocated, your program will probably end abrubtly (ie, if you dont catch the exception) and even if you catch the exception, its pretty much your chance to exit out gracefully.
Another very good example is divide by 0 exception..Another one is stackoverflow exception. When these things happen, your program just can not continue.
Code:
int *p
try {
p = new int[25];
} catch (std::bad_alloc) {
}
In your case (the secure function for example) does not create a major error. You can handle in gracefully because its not an error. Imagine if you recieved a bad SQl query and everytime your program had to exit out because of it. You can simply prevent that by returning true/false and still keep the flow of your program.
Regarding your second concern about returning the new striing you have two choices:
1) modify the query that the class instance already holds. There's absoluetly no need to have a bad query in memory. The secure function should change the field to the new query and return true/false.
2) return empty string. Not as gracefull as true/false and I am not sure how PHP will parse an empty string in an if statement but its another option.