Thread: causing default exceptions to throw additional info

So I've been playing with massive amounts of error handling measures, and for reasons known only to a few shriveled neurons somewhere in the back, I feel like playing with more. My applications should practically debug themselves .

What I'd like to do, is somehow cause default exceptions to throw additional information, such as the file and line number they occured on. I can create my own custom exception handlers but I dont have any info on the standard exceptions.

Code:

try
{
   int * p = NULL;
   *p = 10;
}
catch(...)
{
   printf("The programmer is an idiot in %s at line %i", file, line);
}

My current knowledge indicates that this cant be done, but my current knowledge also indicates that theres always someone who knows more than me.

I've thought about that too. I don't handle exceptions very often though. ;-/ You could define an error handling class and print all file and line attributes from there. I would like to see one that would attempt to recover from the exception, though. That would be most useful.

Well I'm not sure for standard exceptions but you can throw your own custom exceptions. Make a exception class that you can pass the line # and file to then catch it. Just a thought.

A default exception can be thrown on any line in your program, so how would it be able to return specific line information? It seems to me that default functionality requires that the exception not return program specific information.

You can derive your own exception class from the base class exception, and then use one handler to catch both standard exceptions and your exception class by using the type exception& as the parameter for your catch block, but you will have to throw the exception yourself in the try block--something it seems you don't want to do.

C++ exceptions wont alert you to a Dereference-Null situation anyway.....

Your thinking about Structured Exception Handling - a windows tool & a whole other ballgame!

With the exmaple you gave, you couldnt easily get a code line for the error....but you can get a memory address with SEH

Code:

#include <windows.h>
#include <iostream>

LONG Handler(LPEXCEPTION_POINTERS lpep)
{
	std::cout << "An exception was raised at memory location "
		<< lpep->ExceptionRecord->ExceptionAddress;
	return EXCEPTION_EXECUTE_HANDLER;
}

int main() 
{ 

	
	__try
	{
		int* i = 0;
		*i = 10;
	}
	__except(Handler(GetExceptionInformation()))
	{}

}

<<1) Throwing exceptions is resource-consuming.

There's a slight overhead when useing a try/catch block, but hardly anything to notice if you dont end up throwing. Ande if you do, it doesnt really matter IMO.......if you use C++ exceptions properly, you would only throw them when some critical error has taken place - not for normal diagnostic methods. And in the case of a critical error - there's hardly ever any need to optimise for a crash or failure!

"Well yeah I have that new photoediting program - nothing changed from the earlier version, but when it crashes, it does so on average about 20% quicker!!" - If it crashes, it crashes....aim your optomisations at the parts of your program where they will count in the long run!

Thanks for the input guys. Thats pretty much the conclusions I had reached, but I thought I'd just check anyhow on the off chance that someone knew some kind of black magic solution.

My error handling class already catches, logs and reports memory leaks and their point of allocation, and can free memory that has been lost. It also catches and handles most exceptions and carefully logs unusual behavior (such as accessing arrays OOB). Guess I cant have it all.

Thanks again.

Originally posted by Bubba
The only way I know of to retrieve the address of the instruction that caused the exception is to check the registers and look at IP - which most compilers don't let you do. A register, stack, and memory dump at the time of the exception would provide a lot of information - albeit probably too much to wade through.

SEH provides that info.....

In MSVC++ 6.0 you can use the macros __FILE__ for the filename, and __LINE__ for the line number. Would those be of help?

>>__FILE__ for the filename, and __LINE__ for the line number

Yes, i know; But I need a way to cause the exception to expand these macros.

>>A register, stack, and memory dump at the time of the exception would provide a lot of information - albeit probably too much to wade through.

Exactly. The concept is to provide a relevant piece of informatino regarding the exception, which would allow the programmer to rapidly locate (and fix) the problem. I'm working with applications upwards of 52 files averaging 400 lines (955 at most) per source file. Even the headers get up to 200 lines at times. Working with this much extremly OOP based code makes following program execution extremly difficult. That means finding the location of the error and its caller, even harder.

Originally posted by lightatdawn

Exactly. The concept is to provide a relevant piece of informatino regarding the exception, which would allow the programmer to rapidly locate (and fix) the problem. I'm working with applications upwards of 52 files averaging 400 lines (955 at most) per source file. Even the headers get up to 200 lines at times. Working with this much extremly OOP based code makes following program execution extremly difficult. That means finding the location of the error and its caller, even harder.

If it's errors in your code that you are trying to find, why not try an assert?

How they report an error differs with the implementations I have used, but they usually report the line number & file........also, they only operate in a debug mode, and so when you release your (by then) error free release version, they wont hinder it in any way.

I've also seen people add more to assert with an AND statment...
like assert ((foo != NULL) && "More info here");. The latter part doesnt do anything, but if the first expression is false, the assert will kick in and the text will most likely be displayed in the warning - not sure I like this little trick to much, but it's an idea...

Code:

#include <iostream>
#include <cassert>

class foo
{
public:
	void bar(){std::cout << "Lalalala" << std::endl;}
};

foo* GetPtr()
{
	static foo f;
	static int i;
	
	if(++i > 2)
		return 0;
		
	return &f;

}


int main( void )
{
	foo* ptrf = 0;
	for(int i = 0;i < 10;++i)
	{
		ptrf = GetPtr();
		assert((ptrf != 0) && "NULL Pointer Returned!!");
		ptrf->bar();
		
	}	
}

I'm not a big fan of asserts. There really isnt any parts in my code that are "likely" to throw an exception. It just that on occasion, a new piece of code will interface with an old piece of code in such a way that the old (or new) code breaks. Suddenly I have crashing (or erratic behavior) and no way to find out the cause. Possibly its intermittent and so I cant track it with the debugger. Debugging DX apps is hell anyhow.