I'm working on porting a Visual C++ application to GCC (should build on MingW and Linux).
The existing code uses __try { ... } __except(1) { ... } blocks in a few places so that almost nothing (short of maybe out of memory type errors?) would make the program exit without doing some minimal logging.
What are the options for doing something similar with GCC?
Edit: Thanks for the pointer to /EH options in Visual Studio, what I need now is some examples on how to handle signals on Linux. I've found this message from 2002.
What other signals besides SIGFPE and SIGSEVG should I watch out for? (Mostly care about ones that might be raised from me doing something wrong)
Bounty Information:
I want my application to be able to self-log as many error conditions as possible before it exits.
What signals might I get and which would generally be impossible to log an error message after? (Out of memory, what else?)
How can I handle exceptions and (most importantly) signals in a portable way that the code at least works the same on Linux and MingW. #ifdef is OK.
The reason I don't just have a wrapper process that logs the failure is that for performance reasons I save writing some data to disk till the last minute, so if something goes wrong I want to make all possible attempts to write the data out before exiting.
try { xxx } catch(...) { xxx } would be more portable but might not catch as much. It depends on compiler settings and environments.
Using the default VC++ settings, asynchronous (SEH) errors are not delivered to the C++ EH infrastructure; to catch them you need to use SEH handlers (__try/__except) instead. VC++ allows you to route SEH errors through C++ error-handling, which allows a catch(...) to trap SEH errors; this includes memory errors such as null pointer dereferences. Details.
On Linux, however, many of the errors that Windows uses SEH for are indicated through signals. These are not ever caught by try/catch; to handle them you need a signal handler.
Why not use the C++ standard exceptions instead of MSFT's proprietary extension? C++ has an exception handling concept.
struct my_exception_type : public logic_error {
my_exception_type(char const* msg) : logic_error(msg) { }
};
try {
throw my_exception_type("An error occurred");
} catch (my_exception_type& ex) {
cerr << ex.what << endl;
}
C++ also has a “catchall” clause so if you want to log exceptions you can use the following wrapper:
try {
// …
}
catch (...) {
}
However, this is not very efficient in C++ because creating such a general wrapper means that handling code has to be inserted in every subsequent stack frame by the compiler (unlike in managed systems like .NET where exception handling comes at no additional cost as long as no exception is actually thrown).
For portability, one thing to try is using try-catch blocks for most vanilla exceptions and then set a terminate handler (set_terminate_handler) to have a minimal hook available for catastrophic exit conditions. You can also try adding something like an atexit or on_exit handler. Your execution environment may be bizarre or corrupt when you enter these functions, of course, so be careful of how much you presume a sane environment.
Finally, when using regular try-catch pairs you can consider using function try blocks as opposed to opening a try block in the body of a function:
int foo(int x) try {
// body of foo
} catch (...) {
// be careful what's done here!
}
they're a relatively unknown chunk of C++ and may in some cases offer recovery even in the event of partial (small scale) stack corruption.
Finally, yes, you'll probably want to investigate which signals you can continuably handle on your own or on which you might abort, and if you want less handling mechanisms in place, you might consider call the none-throwing version of the new operator, and compiling to not generate floating point exceptions if needed (you can always check isnan(.), isfinite(.), on FP results to protect yourself).
On that last note, be careful: I've notice that the floating point result classification functions can be in different headers under linux and windows... so you may have to conditionalize those includes.
If you're feeling puckish, write it all using setjmp and longjmp (that's a joke...).
Catching C++ exceptions with catch(...) already puts you in a twilight zone.
Trying to catch errors not caught by catch(...) puts you squarely inside undefined behaviour. No C++ code is guaranteed to work. Your minimal logging code may cause the missile to launch instead.
My recommendation is to not even try to catch(...). Only catch exceptions that you can meaningfully and safely log and let the OS handle the rest, if any.
Postmortem debugging gets ugly if you have error handling code failures on top of the root cause.
One way that is easy to use, portable, and barely use any resources would be to catch empty classes. I know this may sound odd at first, but it can be very useful.
Here is an example I made for another question that applies for your question too: link
Also, you can have more than 1 catch:
try
{
/* code that may throw exceptions */
}
catch (Error1 e1)
{
/* code if Error1 is thrown */
}
catch (Error2 e2)
{
/* code if Error2 is thrown */
}
catch (...)
{
/* any exception that was not expected will be caught here */
}
Related
What are the applications and advantages of explicitly raising exceptions in a program. For example, if we consider Ada language specifically here provides an interface to raise exceptions in the program. Example:
raise <Exception>;
But what are the advantages and application areas where we would need to raise exceptions explicitly?
For example, in a procedure which accepts one of the parameters as string:
function Fixed_Str_To_Chr_Ptr (Source_String : String) return C.Strings.Chars_Ptr is
...
begin
...
-- Check whether source string is of acceptable length
if Source_String'Length <= 100 then
...
else
...
raise Constraint_Error;
end if;
return Ptr;
exception
when Constraint_Error=>
.. Do Something..
end Fixed_Str_To_Chr_Ptr;
Is there any advantage or good practice if I raise an exception in the above function and handle it when the passed string length bound exceeds the tolerable limits? Or a simple If-else handler logic should do the business?
I'll make my 2 cents an answer in order to bundle the various aspects. Let's start with the general question
But what are the advantages and application areas where we would need to raise exceptions explicitly?
There are a few typical reasons for raising exceptions. Most of them are not Ada-specific.
First of all there may be a general design decision to use or not use exceptions. Some general criteria:
Exception handlers may incur a run time cost even if an exception is actually never thrown (cf. e.g. https://gcc.gnu.org/onlinedocs/gnat_ugn/Exception-Handling-Control.html). That may be unacceptable.
Issues of inter-operability with other languages may preclude the use of exceptions, or at least require that none leave the part programmed in Ada.
To a degree the decision is also a matter of taste. A programmer coming from a language without exceptions may feel more confident with a design which just relies on checking return values.
Some programs will benefit from exceptions more than others. If traditional error handling obscures the actual program structure it may be time for exceptions. If, on the other hand, potential errors are few, easily detected and can be handled locally, exceptions may obscure potential execution paths more than handling errors traditionally would.
Once the general decision to use exceptions has been made the problem arises when and when not it is appropriate to raise them in your code. I mentioned one general criteria in my comment. What comes to mind:
Exceptions should not be part of normal, expected program flow (they are called exceptions, not expectations ;-) ). This is partly because the control flow is harder to see and partly because of the potential run time cost.
Errors which can be handled locally don't need exceptions. (It can still be useful to raise one in order to have a uniform error handling though. I'll discuss that below when I get to your code snippet.)
On the other hand, exceptions are great if a function has no idea how to handle errors. This is particularly true for utility and library functions which can be called from a variety of contexts (GUI, console program, embedded, server ...). Exceptions allow the error to propagate up the call chain until somebody can handle it, without any error handling code in the intervening layers.
Some people say that a library should only expose custom exceptions, at least for any anticipated errors. E.g. when an I/O exception occurs, wrap it in a custom exception and explicitly raise that custom exception instead.
Now to your specific code question:
Is there any advantage or good practice if I raise an exception in the above function and handle it when the passed string length bound exceeds the tolerable limits? Or a simple If-else handler logic should do the business?
I don't particularly like that (although I don't find it terrible) because my general argument above ("if you can handle it locally, don't raise") would indicate that a simple if/else is clearer.1 For example, if the function is long the exception handler will be far away from the error location, so one may wonder where exactly the exception could occur (and finding one raise location is no guarantee that one has found them all, so the reviewer must scrutinize the whole function!).
It depends a bit on the specific circumstances though. Raising an exception may be elegant if an error can happen in several places. For example, if several strings can be too short it may be nice to have a centralized error handling through the exception handler, instead of scattering if/then/elses (nested??) across the function body. The situation is so common that a legitimate case can be made for using goto constructs in languages without exceptions. An exception is then clearly superior.
1But in all reality, how do you handle that error there? Do you have a guaranteed logging facility? What do you return? Does the caller know the result can be invalid? Maybe you should throw and not catch.
There are two problems with the given example:
It's simple enough that control flow doesn't need the exception. That won't always be the case, however, and I'll come back to that in a moment.
Constraint_Error is a spectacularly bad exception to raise, to detect a string length error. The standard exceptions Program_Error, Constraint_Error, Storage_Error ought to be reserved for programming error conditions, and in most circumstances ought to bring down the executable before it can do any damage, with enough debugging information (a stack traceback at the very least) to let you find the mistake and guarantee it never happens again.
It's remarkably satisfying to get a Constraint_Error pointing spookily close to your mistake, instead of whatever undefined behaviour happens much later on... (It's useful to learn how to turn on stack tracebacks, which aren't generally on by default).
Instead, you probably want to define your own String_Size_Error exception, raise that and handle it. Then, anything else in your unshown code that raises Constraint_Error will be properly debugged instead of silently generating a faulty Chars_Ptr.
For a valid use case for raising exceptions, consider a circuit simulator such as SPICE (or a CFD simulator for gas flow, etc). These tools, even when working properly, are prone to failures thanks to numerical problems that happen in matrix computations. (Two terms cancel, producing zero +/- rounding error, which causes infeasibly large numbers or divide-by-zero later on). It's often an iterative approximation, where the error should reduce in each step until it's an acceptably low value. But if a failure occurs, the error term will start growing...
Typically the simulation happens step by step, where each step is a sufficiently small time step, maybe 1 us or 1 ns. The main loop requests a step, and this request is passed to thousands of agents in the simulation representing components in a circuit, or triangles in a CFD mesh.
Any one of those agents may fail to compute a solution, and the cleanest way to handle a failure is to raise an exception, maybe Convergence_Error. There may be thousands of possible points where an exception can be raised.
Testing thousands of return codes would get ugly fast. But with exceptions, the main loop only needs one handler, which takes some corrective action such as reducing the simulation step size and running the step again.
Sanitizing user text input in a browser may be another good use case, closer to the example code.
One word on the runtime cost of exceptions : the Gnat compiler and its RTS supports a "Zero Cost Exception" (ZCX) model - at least for some targets. There's a larger penalty when an exception is raised, as a tradeoff against eliminating the penalty in the normal case. If the penalty matters to you, refer to the documentation to see if it's worthwhile 9or even possible) in your case.
You raise an exception explicitly to control which exception is reported to the user of a subprogram. - Or in some cases just to control the message associated with the raised exception.
In very special cases you may also raise an exception as a program flow control.
Exceptions should stay true to their name, which is to represent exceptional situations.
I'm programming in Prolog and sometimes I want to get a fail but instead I get an exception, which I can't understand why should be a difference between them. If something couldn't execute that's mean that the predicate didn't succed, so it's a simple fail. Am I missing something?
A failure means that what you're trying to prove is false. An exception means that what you're trying to prove doesn't make sense (e.g. trying to compute the square root of an atom) for some reason or that you bumped into some system limitation (e.g. exhausting available memory).
But you can easily convert any exception into a failure by writing:
catch(Goal, _, fail)
A follow up to: CUDA: Stop all other threads
I'm looking for a way to exit a kernel if a "bad condition" occurs.
The prog manual say NVCC does not support exception handling. I'm wondering if there is a user defined cuda-error-code. In other words if "bad" happens, then terminate with this user error code. I doubt there is one, so my other idea would be to cause one.
Something like, if "bad" happens, divide by zero. But I'm unsure if one thread does a divide-by-zero, is that enough to crash the whole kernel, or just that thread?
Is there a better approach to terminating a kernel?
You should first read this question and the answers by harrism and tera (asked/answered yesterday).
You may be tempted to use something like
if (there_is_an_error) {
*status = MY_ERROR_CODE; // store to device pointer
__threadfence(); // ensure store issued before trap
asm("trap;"); // kill kernel with error
}
This does not exactly satisfy your condition of "graceful", in my opinion. Trap causes the kernel to exit and the runtime to report cudaErrorUnknown. But since kernel execution is asynchronous, you will need to synchronize your stream / device in order to catch this error, which means synchronizing after every kernel call, unless you are OK with having imprecise errors (i.e. you may not catch the error code until after calls to subsequent CUDA API calls).
But this is just the way kernel error handling is in CUDA, and well-written codes should be synchronizing in debug builds to check kernel errors, and settling for imprecise error messages in release builds. Unfortunately, I don't think there is a more graceful way than that.
edit: on Compute capability 2.0 and later you can use assert() to exit with an error in debug builds. It was unclear if this is what you want though.
The assertion may help you. You could find it in B.15 of CUDA C Programming Guide.
what will the program behave when they have two exceptions.
And none of them have been caught yet.
what type of handler will be called .
lets say both the exceptions were of different type.
i apologize if i am not clear but i feel i have made myself clear enough.
thank you!!!
what if the try block throws an exception and try block is exited which destroyes all the automatic variables.Lets say one was an automatic object and its destructor again threw an exception.Now we have two uncaught exception.My question is based on this fact.
thank you!!
It depends entirely on the language. However, in all the languages I know there can't ever be multiple exceptions at the same time (in the same thread). If an exception has been thrown, it travels up the call stack until it's caught, with no code executing during this time. If the exception is not caught, the program crashes before another can be thrown. If it is caught, the exception is no longer "active" and if the handler throws a new exception, the old one is forgotten.
At the CPU level (on x86), there is a situation called a double fault:
On the x86 architecture, a double fault exception occurs if the processor encounters a problem while trying to service a pending interrupt or exception.
However, this kind of "double fault" is a very low level situation and is only of concern to the operating system kernel.
Few languages or frameworks can do a good job of handling an exception that occurs while cleaning up from an earlier exception. Effective handling of such situations would require the cleanup code to know what exception, if any, occurred on the "main line". Conceptually it would not be at all difficult for such information to be provided to cleanup code, but frameworks generally don't provide it.
Otherwise, normal behavior in C++ is to hard-crash the system when an exception occurs during the cleanup from another exception; Java and .NET languages generally abandon any pending exception if a cleanup exception occurs. Newer versions of Java, however, include a feature which (if used) will handles such things much better. In a try-with-resources block, an exception which occurs while cleaning up resources when no other exceptions are pending will be treated normally; if, however, an exception was pending, the pending exception will remain pending but have the new exception added to its list of "suppressed exceptions". It would be nice if there were a way of specifying that a particular finally block should behave the same way, but I don't know of any feature for that.
When Exception is occurred then complier unwind stack(closing current functions and going to back, caller function). If no exception is caught in main than complier called abort function. By this program terminate abnormally.
But during unwinding stack if another exception is occurred(for your case in destructor) than at this time/point without reaching main function, compiler called abort function which terminate program abnormally.
If you know that exception could be occurred in destructor than you must handled in destructor .Means in destructor you should have catch block to catch that exception. By this way second exception generated is to be handled within a destructor and this exception is not out from the destructor and program is to saved from crash due to two exception generated at a time
Complier handle only one exception at a time. If compiler find more than one exception call abort function by which program terminate abnormally.
This is more a general purpose programming question than language specific. I've seen several appraoches to try and catches.
One is you do whatever preprocessing on data you need, call a function with the appropriate arguments and wrap it into a try/catch block.
The other is to simply call a function pass the data and rely on try catches within the function, with the function returning a true/false flag if errors occured.
Third is a combination with a try catch outside the function and inside. However if the functions try catch catches something, it throws out another exception for the try catch block outside the function to catch.
Any thoughts on the pros/cons of these methods for error control or if there is an accepted standard? My googling ninja skills have failed me on finding accurate data on this.
In general, an exception should only be caught if it can actually be handled.
It makes no sense to catch an exception for no purpose other than to log it. The exception is that exceptions should be caught at the "top level" so that it can be logged. All other code should allow exceptions to propagate to the code that will log them.
I think the best way to think about this is in terms of program state. You don't want a failed operation to damage program state. This paper describes the concept of "Exception Safety".
In general, you first need to decide what level of exception safety a function needs to guarantee. The levels are
Basic Guarnantee
Strong Guarantee
NoThrow Guarantee
The basic Guarantee simply means that in the face of an exception or other error, no resources are leaked, the strong guarantee says that the program state is rolled back to before the exception, and nothrow methods never throw exceptions.
I personally use exceptions when an unexpected, runtime failure occurs. Unexpected means to me that such a failure should not occur in the normal course of operations. Runtime means that the error is due to the state of some external component outside of my control, as opposed to due to logic errors on my part. I use ASSERT()'s to catch logic errors, and I use boolean return values for expected errors.
Why? ASSERT isn't compiled into release code, so I don't burden my users with error checking for my own failures. That's what unit tests and ASSERTS are for. Booleans because throwing an exception can give the wrong message. Exceptions can be expensive, too. If I throw exceptions in the normal course of application execution, then I can't use the MS Visual Studio debugger's excellent "Catch on thrown" exception feature, where I can have the debugger break a program at the point that any exception is thrown, rather than the default of only stopping at unhandled (crashing) exceptions.
To see a C++ technique for the basic Guarantee, google "RAII" (Resource Acquisition is Initialiation). It's a technique where you wrap a resource in an object whose constructor allocates the resource and whos destructor frees the resource. Since C++ exceptions unwind the stack, it guarantees that resources are freed in the face of exceptions. You can use this technique to roll back program state in the face of an exception. Just add a "Commit" method to an object, and if an object isn't committed before it is destroyed, run the "Rollback" operation that restores program state in the destructor.
Every "module" in an application is responsible for handling its own input parameters. Normally, you should find issues as soon as possible and not hand garbage to another part of the application and rely on them to be correct. There are exceptions though. Sometimes validating an input parameter basically needs reimplementing what the callee is supposed to do (e.g. parsing an integer) in the caller. In this case, it's usually appropriate to try the operation and see if it works or not. Moreover, there are some operations that you can't predict their success without doing them. For example, you can't reliably check if you can write to a file before writing to it: another process might immediately lock the file after your check.
There are no real hard and fast rules around exception handling that I have encountered, however I have a number of general rules of thumb that I like to apply.
Even if some exceptions are handled at the lower layer of your system make sure there is a catch all exception handler at the entry point of your system (e.g. When you implement a new Thread (i.e. Runnable), Servlet, MessasgeDrivenBean, server socket etc). This is often the best place to make the final decision as how your system should continue (log and retry, exit with error, roll back transaction)
Never throw an execption within a finally block, you will lose the original exception and mask the real problem with an unimportant error.
Apart from that it depends on the function that you are implementing. Are you in a loop, should the rest of the items be retried or the whole list aborted?
If you rethrow an exception avoid logging as it will just add noise to your logs.
I generally consider if as the caller of the method I can use an exception in any way (like, to recover from it by taking a different approach) or if it makes no difference and just went wrong if the exception occurs. So in the former case I'll declare the method to throw the exception while in the latter I'll catch it inside of the method and don't bother the caller with it.
The only question on catching exceptions is "are there multiple strategies for getting something done?"
Some functions can meaningfully catch certain exceptions and try alternative strategies in the event of those known exceptions.
All other exceptions will be thrown.
If there are not any alternative strategies, the exception will be simply thrown.
Rarely do you want a function to catch (and silence) exceptions. An exception means that something is wrong. The application -- as a whole -- should be aware of unhandled exceptions. It should at least log them, and perhaps do even more: shut down or perhaps restart.