Windows Forms

5-Oct-07 2:35

hi,
I m writting an windows forms based application in C# and am facing an unusual problem..I have thrown an exception from a my business logic code but the execution control gets lost after I raise a business exception! WTF | :WTF:

(The business logic code is in a seperate library project)
has this happened with someone? please help..

Scott Dorman5-Oct-07 12:06

5-Oct-07 12:06

I think you're going to need to be a little clearer in the explanation of what's happening before any one will be able to help you.

alesh_nitre wrote:
..I have thrown an exception from a my business logic code

Is this a custom exception or one of the standard .NET exceptions? How are you throwing it?

alesh_nitre wrote:
the execution control gets lost after I raise a business exception

This doesn't make sense to me. What do you mean "the execution control gets lost"?

Scott.

—In just two days, tomorrow will be yesterday.

[Forum Guidelines] [Articles] [Blog]

alesh_nitre7-Oct-07 20:25

7-Oct-07 20:25

Thanks for such an urgent reply and sorry for a lousy explanation! But two days back i myself was unable to locate or reason about the cause of the problem. I'll explain better now. (Please ignore previous post)

About "the execution control gets lost" ->

I was debugging the code using VS2005 debugger pressing F10 and F11 along my way. But the moment the exception was thrown following things used to occur
1. The yellow arrow that shows current executing statement used to get lost
2. The call stack window used to go blank suddenly.
3. The application hung.

The app used to hang even in the release mode and so on.
-------------------------------------------------------------------
Neways. Now that i have better idea why this is happening I have summerised the code as follows. Please have a look at this -

private void button1_Click(object sender, EventArgs e)
{

// this code snippets reproduces the problem i stated

MySqlConnection con = new MySqlConnection("server=192.168.1.45;user id=root;Password=pqrs;database=dev");

//(I am using MySql .NET Connector 5.1.2)
con.Open();
try
{
// Select from any table that ***HAS BLOB DATA FIELD***
string selCmd = "SELECT * FROM document";

using (MySqlCommand allDocsCmd = new MySqlCommand(selCmd, con))
{
//Execute Reader
using (MySqlDataReader reader = allDocsCmd.ExecuteReader())
{
// ... some logic may be while(reader.read()) loop etc.

// Say this code throws an excpeption at some point..

throw new ApplicationException("Any exception ..");

// we expect the the execution control to go in the catch block below but
// it gets lost in the manner i told

}
}
}
catch (Exception ee)
{
MessageBox.Show(ee.Message);
}
}

Scott Dorman8-Oct-07 3:52

8-Oct-07 3:52

The code looks ok to me. Given the explanation, it sounds like you are actually hitting an exception in the MySqlDataReader code. When you get into that state, try pressing the "pause" button on the debug toolbar, which will break the execution and place you on the currently executing line of code. If it can't find the code, it should tell you and give you the option of looking at the assembly code. You could also try narrowing the try/catch by putting it inside the innermost using block directly around the code you think is throwing the exception.

Also, are you using .NET 2.0 or later? If not, you can try adding a blank catch block. It's possible (although unlikely) that the code is throwing an exception that isn't properly wrapped as a .NET exception. The empty catch block will catch that, but you won't have any exception data.

Scott.

—In just two days, tomorrow will be yesterday.

[Forum Guidelines] [Articles] [Blog]

alesh_nitre8-Oct-07 5:16

8-Oct-07 5:16

You are rite! the problem is indeed with MySqlDataReader..
btw I tried what you suggestd.. but pressing pause returned the control to the "throw new App.." statement with the arrow in green color.

To dig further suspected the 'using' blocks in my code made it hang. so I removed them to find that my doubt was right. I closed the reader manually rather than the 'using' doing it for me.. following is the code..

<br />
// Select from any table that ***HAS BLOB DATA FIELD***<br />
string selCmd = "SELECT * FROM document";<br />
MySqlCommand allDocsCmd = new MySqlCommand(selCmd, con);<br />
MySqlDataReader reader = allDocsCmd.ExecuteReader();<br />
reader.Close();

The execution hangs at reader.Close();

This for sure is now a MySqlDAtaReader related problem..I selected everything else but the blob field from the table and it worked fine i.e.
"select id,data from document" hangs but
"select id from document" works ok.
('data' is a LONGBLOB field in document table)

I am searching a cause and fix but lemme know if you have ne idea why this is happening..
Thanx.

Scott Dorman8-Oct-07 5:34

8-Oct-07 5:34

Good to hear that you have tracked down the problem. I'm not familiar with the MySqlDataReader code so I probably won't be able to help you there. The pause button trick works most of the time, but as you found it doesn't work all of the time. It was worth having you try it, just in case.

If you have access to the source code for the MySqlDataReader, you should probably start there and look at what the Close method is actually doing. If not, you can try using Reflector[^] to look at the code.

My guess, since this works correctly as long as you exclude the blob field, is that the blob field is allocating another datatype internally which isn't being properly handled in the Close call.

Scott.

—In just two days, tomorrow will be yesterday.

[Forum Guidelines] [Articles] [Blog]

alesh_nitre9-Oct-07 20:36

9-Oct-07 20:36

I will work on the reader.Close() and put a small update here so that others get help if they bump in to this kinda problem..neway. the "press pause button" trick is helping when everything seems 'frozen'. The green arrow appears and pressing F10 shows this messsage

The CLR has been unable to transition from COM context 0x191288 to COM context 0x1913d8 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.

Scott Dorman10-Oct-07 3:31