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.
Related
Taken from the Intel 80386 Programmer's Reference Manual, CH9:
Exceptions are classified as faults, traps, or aborts depending on the way
they are reported and whether restart of the instruction that caused the
exception is supported.
Aborts: An abort is an exception that permits neither precise location
of the instruction causing the exception nor restart of the program
that caused the exception. Aborts are used to report severe errors,
such as hardware errors and inconsistent or illegal values in system
tables.
(Emphasis mine)
What does it exactly mean that aborts are exceptions that do not permit precise location of the instruction causing the exception?
There's only 2 "abort" exceptions:
a) Double fault exception. This happens when trying to start one exception caused a second exception; where the instruction pointer (saved by CPU when starting the double fault exception handler) could be from the original instruction, the first exception, the second, something else or nothing. In this case, because the CPU couldn't start the first or second exception handler you can't return from the double fault to the second (or first) exception handler anyway.
b) Machine check exception. This is purely for hardware faults where you probably don't want to assume that memory, or caches, or the CPU actually work. You can't expect "guaranteed behavior" from faulty hardware.
Note 1: Technically, for some causes of machine check, you can return to the precise location of whatever happened to be interrupted by the exception; you just need to be very careful about determining if you can/can't return (and need some way to fix/work-around the hardware problem/s so that returning from the machine check exception handler won't just trigger a second machine check exception).
Note 2: It's perfectly possible for the exceptions preceding a double fault, or machine check, to be caused by something that isn't an instruction at all (e.g. caused by an IRQ). In these cases "the precise location of the instruction causing the exception" would be "the precise location of something that doesn't exist". Intel's words should be interpreted as being conditional (like "an exception that permits neither precise location of the instruction causing the exception if there is one, nor restart of the program that caused the exception if there is one").
Is writing one rescue clause at the end of a program to end the program in Eiffel enough to handle exceptions such as pre, postconditions or invariant violations in any of the routines written in the program? Or should I write rescue clause for every function having pre and postconditions to handle exceptions?
I have read Eiffel documentation on error handling but I couldn't figure out.
The answer depends on your expectations. The method is as follows:
Precondition violations are reported to the caller. They indicate a bug in the caller. If bugs are expected or possible in the callers, you can catch and handle them in the callers.
Postcondition violations are reported to the callee. They indicate bugs in the callee. The callee can catch and handle them if such bugs are expected.
Class invariants are established at object creation. If they are violated by the creation procedure or after the execution of a procedure used in a qualified call, they indicate a bug in the callee and can be handled like postcondition violations. Otherwise, they indicate more complex issue involving object dependencies. It could be handled by the caller, but most likely it would be next to impossible to restore correct object state.
In all cases, assertion violations mean a program bug and whether and how it should be caught and handled depends on your needs. E.g., it's possible to do the handling somewhere between the problematic code and the root procedure.
I've been studying assembly lately and i can't seem to understand how the exceptions work exactly. More specific, i get the message Exception 6 occurred and ignored. Can someone please explain what exactly does this mean? I am using qtspim.
Exceptions may be caused by hardware or software. An exception is like an unscheduled function call that jumps to a new address.
The program may encounter an error condition such as
an undefined instruction. The program then jumps to code in the operating system (OS), which may choose to terminate the program. Other causes of exceptions are division by zero, attempts to read some nonexistent memory, hardware malfunctions, debugger breakpoints, and arithmetic overflow.
The processor records the cause of an exception and the value of the PC
at the time the exception occurs. It then jumps to the exception handler function. The exception handler is code (usually in the OS) that examines the
cause of the exception and responds appropriately, It then returns to the program that
was executing before the exception took place.
In MIPS, the exception handler is always located at 0x80000180. When an exception occurs, the processor always jumps to this instruction address, regardless of the cause.
The MIPS architecture uses a special-purpose register, called the Cause
register, to record the cause of the exception.
MIPS uses another special-purpose register called the Exception
Program Counter (EPC) to store the value of the PC at the time an
exception takes place. The processor returns to the address in EPC after
handling the exception. This is analogous to using $ra to store the old
value of the PC during a jal instruction.
I'm trying to identify a bug in a program (32bit) which could probably lead to code execution. So far I debugged the application with ollydbg and ran my exploit code. Then ollydbg gives me an exception.
If I press "Ctrl+F9" nothing seems to be executed of my shellcode
In contrast when the exception occures and I step through the next instructions with "F8" I finally reach my shellcode and it gets executet
If I run the application without ollydbg, my shellcode also doesn't get executed
Why does my shellcode get executed when I step to the next instructions an otherwise not? What's then the normal case when I run my application without a debugger?
Thanks a lot!
When an exception is raised in a thread the system will first check if a debugger is attached.
If a debugger is attached the exception is reported to the debugger (and not to the faulting process or thread). In ollydbg (and most debuggers) you then have the choice to do something with that exception.
The 1st one is to pass that exception to the faulting thread (CTRL+F9) in ollydbg.
The system will look at the EXCEPTION_REGISTRATION_RECORD for the current thread and walks the list of EXCEPTION_REGISTRATION structures (each of these structures has an exception handler) and check if a handler can handle the exception.
If a handler can handle the exception, the stack is unwind (to a certain point) and the thread might continue its life.
If no handler can handle the exception, the final handler is called and the program crashes (the system will then usually display a dialog box informing the user that the process crashed).
This is exactly the same behavior in the case no debugger is attached.
Thus, in your case, passing the exception to the debugger will probably unwind the stack, and the thread will continue its execution after the location of the exception (or simply crash the whole application if the exception couldn't be handled).
The second option - when a debugger is attached - is to not pass the exception to the faulting thread (using one of the step [into | over] / run button). In this case the system will not search for any handler and the thread will either simply rethrow the exception (if it can't pass over it) or continue execution like nothing happened (if the debugger knows how to handle it).
You should check which type (most probably one of: Access violation in read / write ; breakpoint exception) of exception is raised and correct the problem (see at the bottom of the ollydbg window, it will tell you which kind of exception has been raised) if you want to execute your shellcode without problem.
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.