Home » U++ Library support » U++ Widgets - General questions or Mixed problems » how to input an int into std::string? and an exception question
 how to input an int into std::string? and an exception question [message #13362] |
Thu, 03 January 2008 04:10  |
 |
bonami
Messages: 186
Registered: June 2007
Location: Beijing
|
Experienced Member |
|
|
iota is good, but that is for char *.
i used std::stringstream, which accepts int well, but when i convered it into std::string and threw it, my program crashed.
std::stringstream msg;
msg << "failed to bind to " << localSocket->ip() << ":" << localSocket->port()/* this is an int */;
throw std::string(msg.str()); //or simply throw msg.str();
...
catch (std::string err) ...
& i want standard C++ method, not String or alike.
another question is why my functions cannot throw an exception by default
child() {... throw std::string("error"); }
dad() {... child(); ...}/*crashes*/
mum() {... try { child(); }/*this works*/
catch (std::string err) { throw err; }}
grand() {... try { dad()/* or mum()*/; }
catch (std::string err) {....}}
today i just ran mum() again, and it crashed, too... (since i had been Debuggin, i could locate the last sentence is throw)
[Updated on: Thu, 17 January 2008 07:05] Report message to a moderator |
|
|
|
| Re: how to input an int into std::string? [message #13368 is a reply to message #13362] |
Thu, 03 January 2008 13:18  |
 |
tvanriper
Messages: 85
Registered: September 2007
Location: Germantown, MD, USA
|
Member |
|
|
When you throw an exception, if you have no way to catch that exception, it will crash your program.
That's actually kind of the point behind exceptions.
If you never want your program to crash due to an exception, but want it to die gracefully, you have to provide some way to handle all exceptions. Sometimes, this is accomplished in main with something like:
int main( int argc, char** argv )
{
try
{
millions_of_functions();
even_more_functions();
maybe_yet_more_functions();
}
catch( ... )
{
// Some error handling routine here... like maybe:
std::cerr << "Something catastrophic happened." << std::endl;
}
}
So, based on what I'm reading in your message, I do not see the nature of your problem. It looks to me that your program should be crashing, since you're asking it to do so.
Generally, the folks experienced with C++ that I've talked to seem to agree that exceptions should be used in very rare cases, and ought to be avoided if possible. You might only use exceptions for truly exceptional situations, where you can see that the system will have a serious problem that destabilizes memory or registers, and want to clearly indicate where the problem occurred so you can fix it more easily.
If you can, you should try to indicate most error conditions through other means, perhaps through an error state, return code, or something you change in a parameter.
|
|
|
|
| Re: how to input an int into std::string? [message #13370 is a reply to message #13368] |
Thu, 03 January 2008 14:39 |
mr_ped
Messages: 826
Registered: November 2005
Location: Czech Republic - Praha
|
Experienced Contributor |
|
|
bonami: the mum should crash too, as you do another throw in the catch clause, which is not catch anywhere.
| tvanriper wrote on Thu, 03 January 2008 13:18 |
Generally, the folks experienced with C++ that I've talked to seem to agree that exceptions should be used in very rare cases, and ought to be avoided if possible. You might only use exceptions for truly exceptional situations, where you can see that the system will have a serious problem that destabilizes memory or registers, and want to clearly indicate where the problem occurred so you can fix it more easily.
If you can, you should try to indicate most error conditions through other means, perhaps through an error state, return code, or something you change in a parameter.
|
I think it's about how the source code looks.
If the exception version looks shorter and cleaner and is easier to read and understand, you should use it, even if it is not serious problem state what is handled there.
If the "if" version with error return codes looks good enough, the exception version would likely look more complex.
In case of performance critical code you should benchmark final version with profiler, and rewrite only the most critical code parts, with proper comments why you are using more ugly (but faster) code in that space and how it improves performance.
And you should try to create some policy for your project where/why to use exceptions, so they are used in similar context trough whole source (my biggest problem with them, often two different components from me are written in different way, one does use exceptions a lot for error states, other does use if/return extensively, especially if rewrite with different error handling would lead to similar source code and there's no clear winner).
But I don't think there's any major reason to avoid exceptions for all costs. Especially if they will make the source code easier to understand and easier to maintain/change later.
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Fri May 09 11:35:32 CEST 2025
Total time taken to generate the page: 0.00442 seconds
|
Members
Pages
Help
Register
Login
Home
