ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I want to be able to set a string to something like null. And it should not be "" since it can be a valid value.
My function is supposed to look inside an stl vector and return the string at a specified index.
However, if the index is not valid I need a way to return something that will indicate this. And since "" is a string I cannot return that. And I cannot return null either cause that makes the compiler complain.
So I was wondering if there is anything like string::no_val or string::null or something like that which I can use?
I ran into the same problem a few years ago myself. I was designing a data-input interface and the return was a reference to a string but I needed to indicate an error somehow. Since the interface was an abstract class, I just added an EOF-checking function so if the user of the interface came up with a "" then they could check the EOF function to see if it was the end of data or just a blank line. That's another option.
I think the "C++ way" to do this would be to not return anything if you don't have a valid string - throw an exception. You don't have to go into deriving a complicated exception class, if there's only one thing that can go wrong (null string) then you can just throw an int.
Exceptions add a lot of extra stuff to a program, though. Also, I think it's very irritating that the STL does that for things like assigning NULL to a std::string when it really doesn't have to (notwithstanding the standard.) I don't know that the "C++ way" is to throw an exception for a mere error; only if it's something so logically flawed that it doesn't make sense to justify it with a normal error (such as accessing a container element that's outside of the container's boundaries.)
I don't know that the "C++ way" is to throw an exception for a mere error; only if it's something so logically flawed that it doesn't make sense to justify it with a normal error (such as accessing a container element that's outside of the container's boundaries.)
Originally Posted by Ephracis
...However, if the index is not valid I need a way to return something that will indicate this.
Here is what the Language creator has to say.
The C++ exception handling mechanisms are provided to report and handle errors and exceptional events. However, the programmer must decide what it means to be exceptional in a given program. This is not always easy. Can an event that happens most times a program is run be considered exceptional? Can an event that is planned for and handled be considered an error? The answer to both questions is yes. "Exceptional" does not mean "almost never happens" or "disastrous." It is better to think of an exception as meaning "some part of the system couldn’t do what it was asked to do." Usually, we can then try something else. Exception throws should be infrequent compared to function calls or the structure of the system has been obscured. However, we should expect most large programs to throw and catch at least some exceptions in the course of a normal and successful run.
I'd say only use an exception if there's a reasonable way to always prevent one that's argument related. In other words, the programmer should be able to avoid an exception by having enough info available to determine if the index is valid. If they choose to disregard that information and still provide a potentially-invalid index then one might consider that malformed code and an exception would be in order.
Exceptions are dangerous a lot of times because they are effectively just a longjmp to the nearest exception handler. This means that unmanaged dynamic memory could be leaked if the stack doesn't contain cleanup code to execute when it unwinds (such as a std::auto_ptr.) It's a bad idea to have an exception thrown across a C function for this reason (i.e. a C function calling a C++-backed function that throws an exception) because C doesn't provide that sort of memory-management ability. In any *nix-specific program it's nearly impossible to avoid that sort of C, so I think significant caution is in order if you intend to support that type of program.
It's fun to follow the discussion. Well I went with the usage of a reference and a bool return value, however. And it works.
Thought the discussion about using exceptions are interesting. I haven't been very good at using any exception in my code (ever). So maybe it's time to start now (sigh, another thing to put on my never-ending todo-list).
Originally Posted by ta0kira
I'd say only use an exception if there's a reasonable way to always prevent an argument-related function. In other words, the programmer should be able to avoid an exception by having enough info available to determine if the index is valid
Actually the developer of the plugin who will call this function has enough information. He can ask how many items there are and of course you cannot have an index below zero. So maybe the best practice would be to use an exception here?
Even if you provide an exception, there's no guarantee that the using program will ever see it. The developer can compile either using static built-in C++ libraries, which will prevent an exception from leaving the library itself.
I think returning bool is good enough. If you were returning a reference to a string, however, that might be a good time to use one. Exceptions are unfriendly because their default handling is to end the program. I think it's ironic that modernity supposedly supports exceptions but discourages jumps and gotos. It would be quite a bit different (and more useful) if an exception handler was called in the same way a signal is handled (but with all of the benefits of the C++ portion,) then returned to the instruction immediately after the exception.