Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm building a c++ server library, where the user of the library will implement responses to the clients. If the program encounter any runtime error in the response implementation, the server should not exit, it should just close thread/connection.
I've found two ways to doing this.
Use threads and use __try __except in order to catch the exceptions, for example access violation - close the thread.
Start a new process for each connection. Response time to the clients will be longer if not reloading the processes, and will use more RAM.
I'm mainly interested in the first alternative, but it's not recommended in any forums or papers that I've read.
The point is to make the server stable and never terminating.
What option should I use?
the user of the library will implement responses to the clients. If the program encounter any runtime error in the response implementation
If you do not control 100% of the code being executed, going multi-process is the only way to make this stable.
Catching any "crash" SEH exceptions is a brittle business. The code may have bugs that don't cause any exceptions whatsoever, but just overwrite memory and you get some wrong behavior later on.
You could still catch these exceptions, but once you catch one, you should terminate the process, since you can't know what else has been messed up in the process' state. (And a better way might actually be to not catch them and just let the process terminate, giving you the chance to collect a crash dump.)
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 3 years ago.
Improve this question
I am trying to learn winsock2 by following a tutorial. The problem is that the last section where it tells you about handling multiple clients, has empty code. How would this be achieved with multi-threading in a nice-mannered way?
Code: https://pastebin.com/D3L8CgAi
Since links to pastebin must be accompanied by code, I need to add this.
To clarify: I would not use threads to handle multiple clients.
To your question:
1 thread should listen for new connections.
When a connection is accepted a new socket is created.
For each accepted socket: create a thread for reading/writing to that socket.
The reason I would not implement it this way, is because it will not scale well. After ~100 concurrent connections (maybe more, maybe less) the process will crash due to out of memory. (Threads are expensive).
Google "multi thread socket windows C++" you should find numerous examples including videos with explanations.
If you really want to create a scalable server review libraries such as libevent (which wrap asynchronous mechanisms such as epoll).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I am having a custom exception class for my library. I would like to know whether I should register an SEH handler and catch CPU exceptions such as access violation, illegal instruction, divide by zero. I then can report these to the client of my library that a CPU exception has occurred.
Unless you are writing a specific system-related library that really require that, you shouldn't register SEH handlers. If you do that, you are hiding errors to the application.
First rule should be not handling SEH exceptions and allow the application to do it as they were configured.
But if you expect that the program could be crash because an exception when invoking your library (for instance, because it calls to an external API that you know that could raise an exception), you must evaluate if it worth to catch them to take any action (like report an error). But in that case, limit the scope of the exception protection and the filter the narrower as possible.
If the system exceptions are caused by your own code, it shouldn't be hidden and them should be fixed soon.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
This question was brought to me because I was watching this talk
A large part of the second half of the talk is spent kinda going back and fourth about exception vs non exception handling in c++.
I am working mainly with c but I would like to get some experienced programmers help understanding this.
I haven't written any code that really did anything with exceptions, I have done java code and that basically forces you to add try/ catch blocks etc.
When he says exception handling vs non exception handling does that mean the way java almost forces you to add those blocks around any unsafe code while in c basically if you don't remember to do it your app will just crash?
You have to take into consideration that exceptions are usually constructs of Object Oriented programming - That's why Java, C#, C++, etc. often talk about exceptions and try/catch blocks.
In C, this isn't the case. Usually errors need to be caught by the programmer by ways of return values (The C standard uses the errno to keep track of any errors values returned by certain functions).
If something goes really wrong, C will either crash or have an unexpected behaviour - This is where exceptions come in. They are fancier constructs to determine where, how, and why something went wrong.
There is no way of making exceptions in C, but something similar could be done with POSIX signals - though not recommended unless you really know what you are doing. Preferably, use return values to determine when someone goes wrong/right.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a file based hash table thing that can run into various filesystem or user errors. Initially I created all the data functions as bools like
bool add(int key, int value)
bool get(int key, int &value)
and so on where the input/output would go through the parameters and the success/fail would come as the function result.
Then I had some mmf wrapper classes I needed to fool-proof for the same project and I realized that they can fail at the constructor in which case returning a bool is not really an option so I added a bunch of
if (!somethingthatindicatesfail) throw std::exception("description here");
to them.
So now i have something that throws exceptions inside something that returns a bool and then there is system error codes that I also need to include in the error log.
Its a mess.. I'm going to rewrite all of the fail scenario logic but before I do, what is your preferred error handling/conveying method?
The end result I'm imagining is a module that doesn't crash but logs the errors, prevents further damage to the data and advises the user to shut it down.
As you already pointed out, you can't use return codes from constructors. So, if you want a single method that works for all the code, your only real choice is exception handling.
Note, however, that in some cases, it's preferable to just abort instead. In particular, exceptions will attempt to unwind the stack, but if the situation is dire enough, it's possible that could cause further damage, and aborting (existing without unwinding the stack) is a better option.
For that case, it can make sense to have (for example) a separate watch-dog that logs the problem and re-starts the program when/if it crashes. Being a separate process, it can continue and execute reasonably even if the program itself is bollixed up to the point that its only reasonable choice is to abort.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
the idea I have about using exceptions and try {} catch {} blocks is that those are used for error handling.
I was reading Bjarne's Strostrup FAQ page section about exceptions and I came across this
There are other uses of exceptions - popular in other languages - but
not idiomatic in C++ and deliberately not supported well by C++
implementations (those implementations are optimized based on the
assumption that exceptions are used for error handling).
What are other usages for exceptions in other languages (C# or java for example)?
In Python, in the spirit of "ask for forgiveness, not permission", exceptions are frequently used as part as the normal control flow of the application. For instance, when looking up an element in a dictionary (think std::unordered_map in C++):
try:
my_value = my_dict["the answer to life, the universe and everything"]
except KeyError:
my_value = 42
In C++, this is not considered an "erroneous" situation; exceptions should only be used in interaction with "unpredictable" things like hardware devices and (to some degree) the operating system.
One other use is InterrutedException in java. It allows waiting on monitors or sleeping threads step out of wait or sleep.