Jump to content
  • Advertisement
Sign in to follow this  
DrjonesDW3d

[.net] Throwing custom exception from a .dll

This topic is 4812 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I am having a rather interesting problem at the moment. I have a program written in C# that uses a .dll I wrote (also in C#). The user program calls a function from the .dll that does something, then if something goes wrong throws a custom exception. The user program then catches the exception and does some error handling. The wierd part is, that there is an uknown delay of a few seconds between the .dll throwing the exception, and the error handler in the client program catching it. Furthermore, even though it is a separate thread in the client program that is making the call to the .dll, all threads in that program seem to halt, and no code from it (in the other threads) is executing. The strange thing is, if I don't throw my custom exception, but throw a normal Exception, there is no delay. I thought it might be something with my exception, but it's so simple I don't see where it could be getting hung up, plus using error messages it seems like it fully exits the .dll code and is stuck somewhere in the transition. Anyway here is the exception code:
	public class MyException : Exception
	{
		public int  ErrorNum;
		public MyException (int err) 
		{	
			ErrorNum= err;
		}

		override public string ToString() 
		{
			char[] s = new char[255];
			getErrorMessage(ErrorNum, s);
			string str = new string(s);
			return str;
		}

	}

the ToString() part doesn't seem to be it, since the delay happens before that is called. Does anyone know what might be causing this? Is there something with the way the exception class is defined that is wrong? Or is there some rule somewhere about not passing custom exceptions from .dlls to normal code for some strange reason, or perhaps is there some extra step I have to take because it's custom (like casting or something)?

Share this post


Link to post
Share on other sites
Advertisement
Maybe it has to do with the Garbage Collector? Since you never know exactly when it kicks in maybe it kicks in before the actual catch with a custom exception and after the catch otherwise? Don't ask me why it would do that, this was just a theory that poped up in my head :)

Share this post


Link to post
Share on other sites
Made a really simple example and seemed to learn some more things.

Right now I am throwing an ApplicationExtension (standard .NET kind) from one object in a napespace to another (not using a .dll, they are defined in the same file) and still seeing the same kind of delay when catching it. Same thing for a custom exception, but a standard Exception goes through fine. Even in the same object there seems to be something wrong.


static void Main(string[] args)
{

Console.Out.WriteLine("Starting " + Environment.TickCount);

try
{
Console.Out.WriteLine("before throw " + Environment.TickCount);
throw new ApplicationException();
Console.Out.WriteLine("after throw " + Environment.TickCount);

}
catch(Exception e)
{
Console.Out.WriteLine("caught " + Environment.TickCount);
}
finally
{
Console.Out.WriteLine("finally" + Environment.TickCount);
}

Console.In.ReadLine();
}


Anyone have any ideas?

Share this post


Link to post
Share on other sites
Ok, figured it out. It seems to be related to running a program from inside Visual Studio. It seems to run it inside the debugger even when a release build is being made. For some strange reason there is a roughly 4 second delay when throwing an exception that isn't an Exception (ie inherited one) inside the debugger. Running the .exe on another machine or outside visual studio does not have the delay. Seems like that's kind of a big thing since exceptions are suposed to be fairly common and widely used in 'proper' programming. You'd think that something like a 4 second delay each time one is thrown while the debugger is running would of been something they noticed and fixed.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!