[RESOLVED] Getting error and cannot seem to TRY/CATCH it

[szlamany]

I am getting this error

First-chance exception at 0x0f7247b5 (StringLibrary.dll) in Librarian.exe: 0xC0000005: Access violation reading location 0x02e028b8.

And I assume it's in this piece of code - as I can set a break at the start of the routine - and it never arrives at the bottom of the routine.

I have never used TRY/CATCH statements - but why wouldn't this work - why is it not breaking in the CATCH?

			try {
				int s1 = nKeywordskt;
				int s2 = s1;
				int s3 = 0, s4 = 0, s5 = 0, s6 = 0;
				int a = 0;
.
.
.
				s1 = 0; // dummy line
			} catch (int errCode) {
				errCode = errCode;
			}

I set a break at this line int s1 = nKeywordskt and at the s1 = 0; // dummy line and also at the errCode = errCode line.

It breaks at the top - and never arrives at the bottom (getting the error noted at the top of this post instead).

But why does it not arrive in the CATCH??

[Atheist]

In the case of errors like that, no exceptions are thrown so there is nothing to catch.

However, I cant see anything in your code that could cause an access violation, which generally occurs when you are trying to access memory that is not yours. Uninitialized pointers or pointer arithmetics gone bad can be causes for that error.
Here is an example of an access violation:

int a = 5;
int b = 10;

int *p_a = &a;
int *p_b = 0;

int result = *p_a + *p_b; // Trying to use incorrectly initialized pointer p_b.

[szlamany]

The ... in the code represents me cutting out the SHELL sort where I'm alphabettically sorting a pointer array that points to words in a string buffer.

I know I'm doing something evil to memory - I just wanted to CATCH it so I could find it more "easily".

[techgnome]

It's because your catch syntax is off... you catch exceptions... not codes...
http://msdn.microsoft.com/en-us/library/0yd65esw.aspx

Although the catch clause can be used without arguments to catch any type of exception, this usage is not recommended. In general, you should only catch those exceptions that you know how to recover from. Therefore, you should always specify an object argument derived from System.Exception

it should look something like this:

catch (InvalidCastException e) 
{
// error handling here
}

you can also catch multiple exceptions

catch (FileNotFoundException e)
{
    // FileNotFoundExceptions are handled here.
}
catch (IOException e)
{
    // Extract some information from this exception, and then 
    // throw it to the parent method.
    if (e.Source != null)
        Console.WriteLine("IOException source: {0}", e.Source);
    throw;
}

[szlamany]

That is C# - does it also go for C++

[Atheist]

tg, I think you are looking at the C# documentation. It is possible to throw and catch types that are not exceptions. For instance, this is valid:

	try
	{
		throw "foo";
	}
	catch(const char *message)
	{
		std::cout << "Caught: " << message;
	}

[szlamany]

So CATCH can only be used when you do your own THROW - is it that kind of construct?

[Atheist]

So CATCH can only be used when you do your own THROW - is it that kind of construct?

Yes that is right.

[techgnome]

That is C# - does it also go for C++

My bad... I thought we were in the C# area...

tg, I think you are looking at the C# documentation. It is possible to throw and catch types that are not exceptions. For instance, this is valid:

	try
	{
		throw "foo";
	}
	catch(const char *message)
	{
		std::cout << "Caught: " << message;
	}

I was... didn't realize this was in the C/C++ area...

Sure that's valid.. but that can't be the only way catch works, can it? otherwise what would be the point?

-tg


edit - hey... does this help? http://www.cplusplus.com/doc/tutorial/exceptions/

[szlamany]

That link talked about

Catch (...)

using the "..." to catch the default error condition...

But that still did not work - it will not break in that CATCH statement.

Oh well...

[Atheist]

Sure that's valid.. but that can't be the only way catch works, can it? otherwise what would be the point?
http://www.cplusplus.com/doc/tutorial/exceptions/

Im not sure what you mean by that, but the exception handling works similarly to .NET. You can define your own exception and throw it, and the first appropriate catch clause will handle the exception.

#include <iostream>
#include <exception>

class fooexception : public std::exception
{
public:

	fooexception(const char *message) : std::exception(message)
	{
	}
};

int main(int argc, char **argv)
{
	try
	{
		throw new fooexception("Oh no!");
	}
	catch(fooexception *ex)
	{
		std::cout << "Caught fooexception: " << ex->what();
	}
	catch(std::exception *ex)
	{
		std::cout << "Caught std exception: " << ex->what();
	}
	

	// getchar here just to get an opportunity to look at the output.
	getchar();

	return 0;
}

[szlamany]

From what I just researched things like access violations are more of a hardware exception. If AV's were by default "catchable" then it would be a huge performance hit.

On top of the fact that an AV is not safe to CATCH and continue - I've obviously attempted to do a bad memory thing and was caught...

I really need to give up on trying to debug why this latest attempt at adding new logic is flawed and instead go back to a version of this routine that worked a week ago and attempt to add the logic again but using some safer approaches (I was getting a bit carried away with working the arrays that VB.Net is giving me from the managed-side of this app).

I'm going to mark this thread resolved - thanks for the lessons!

[techgnome]

Im not sure what you mean by that, but the exception handling works similarly to .NET. You can define your own exception and throw it, and the first appropriate catch clause will handle the exception.

#include <iostream>
#include <exception>

class fooexception : public std::exception
{
public:

	fooexception(const char *message) : std::exception(message)
	{
	}
};

int main(int argc, char **argv)
{
	try
	{
		throw new fooexception("Oh no!");
	}
	catch(fooexception *ex)
	{
		std::cout << "Caught fooexception: " << ex->what();
	}
	catch(std::exception *ex)
	{
		std::cout << "Caught std exception: " << ex->what();
	}
	

	// getchar here just to get an opportunity to look at the output.
	getchar();

	return 0;
}

What I was commenting about was the comment about the only way a catch works is if you throw it...
Yes, it's valid... but then this transpired...
szlamany asked "So CATCH can only be used when you do your own THROW " ... and you replied with "Yes that is right." ...
which made me question what good is the try catch if it only catches exceptions YOU throw?

-tg

[Atheist]

Ah I see. Well I assumed szlamany did not literally mean "throw statements that he himself has written" but rather "explicit throw statements in the code". My bad, I should have been clearer.

[szlamany]

Ok - just to clarify all this...

1) You can do your own THROW's (you all have shown that in examples above)
2) THROW's happen in other places - functions and layers below you
3) CATCH will only catch a "matching" type - CHAR or INT - basically it's based on TYPE DECLARATION
4) Things like AV's are not CATCH-able

Counter-point to #4 - it seems there are some VS IDE project settings that might get it to do an IDE break when the AV error happens - not sure how safe it is to debug around at that moment anyway. I've seen that this type of AV error is so nasty that I usually have to exit VS and re-start it to get good runs afterwards...

[Atheist]

I am not aware of a windows equivalent, but if you ever do some c++ on linux you should really try Valgrind. It is absolutely invaluable for debugging memory issues.

I know its probably not applicable in this situation, just wanted to mention it

[szlamany]

My goal is to avoid memory issues by carefully stepping through new code and testing "start" of loop and "end" of loop and buffer offset calculations really, really carefully. I cannot be burned by this code - it's going to run in a background service and cannot fail.

That's why I don't mind going back 20 hours in coding to a stable point and re-implementing this new logic with a better and safer approach.

Reading through 500,000 bytes of text and doing word discovery and complex word pattern discovery has been both painful and rewarding.

I am actually finding that I really like C++