Thread: A little program I wrote for fun !

Obviously my mind is set on a different path than yours, which is exactly why I asked how you would do it.

And what if the error occurs in the middle of a long stack of nested functions? Are you going to put if statements in every function to check if an error occurred and return if it does?

Then I suppose we just have to agree to disagree.

Bad can be a difficult thing to define. What matters is that code is readable, flexible and easy to maintain. Any way of designing to code to achieve this is a good thing. But this can be done in a number of ways, including mine and your style.
If the design achieves this goal, then I would not call it bad.

I could equally well call your style bad since it leaves a lot of clutter around with lots of if statements and error handling. It would be beneficial to centralize this to one place.
Leave just enough code to properly diagnose the error and leave it up to the parent to handle errors that cannot be locally handled.

Is that what you're concerned about? I don't really do that. It was an example.
I might see maybe 3-4 nested functions, but that's it.

Basically:
Command handler
--> Part of the command handler (split because the function is too long)
--> Utility function wrapper
--> Utility function

But I would use exceptions instead of if statements to handle errors. Using if statements to check for return is usually for library functions (such as those returning iterators).

I wouldn't return "NULL". Returning an empty string would be easier for everybody.

Code:

string auxiliary_p(string s)

If you can, prefer passing large and complex objects by const reference (that is, unless you indeed want a copy to be made)

Code:

string auxiliary_p(const string& s)

Code:

    string ret("placeholder");
    istringstream in(s);
    in>>ret;

I don't think filling the string with "placeholder" is necessary.

Code:

bool answer(string s)
{
    short n(s.size());
    while(n>1)
        n%=2;
    return static_cast<bool>(n);
}

This seems to be a longwinded way of doing

Code:

bool answer(const string& s)
{
    return s.size() % 2 == 1;
}

That doesn't make the answer particularly random, though. The same question always receives the same answer. Picking a random answer might involve something like

Code:

bool answer()
{
    return std::rand() % 2 == 1; //include <cstdlib>
}

Code:

bool yn

The meaning of a parameter with a name like that might be a bit unclear.

Thank you for the informative answer.

That doesn't make the answer particularly random, though. The same question always receives the same answer.

^That was my intention. The same question getting differently answered seems a little weird.

The filling with "placeholder" was a remnant from the time I was putting together the main() without the actual implementations

.Also, the advice for calling by const reference is one I'd start following from now.

"return s.size() % 2 == 1;" ...I love shortcuts.

Originally Posted by Elysia

That seems like a waste of exceptions. Exceptions are good for breaking the flow of code. That is, if something happens that means you need to abort your program flow, then exceptions are good. That usually means errors.
Of course, we must define an error. It might be perfectly fine for a function to not find any results and it not being an error. Based on what the OP said about the requirements of the whole thing, it looks like syntax errors might be a good exception, but no match might not be a good exception.

Yeah, if you have a recursive parser, exceptions can be the best way to deal with a syntax error. Or any other error that forces an abort. But you usually don't write programs that are intended to error out most of the time.

But I wouldn't use exceptions for bad user input in a text field. And that's what the OP's example would be.

Just wrote a gui wrapper to the program ..using QT. Download .This is my first gui program that actually does something.