Exception Handling...

[Jacek Jurkowski]

Why in thet case "throw" doesn't work?
There is no exception rising and there should
be!

public class Aaa
{
public static void Main()
{
try
{
Bbb bbb = new Bbb();
bbb.ShowDialog();
}
catch(Exception e)
{
MessageBox.Show(e.Message);
}
}
}

public class Bbb : Form
{
protected override OnLoad(EventArgs e)
{
base.OnLoad(e);
throw new Exception("exception");
}
}

 

[Marc Gravell]

It works just fine for me... what are you expecting? And what version of
..NET are you using?

Load happens as the form is preparing to display (i.e. during ShowDialog,
not during the constructor); this throws your exception, which is shown via
the MessageBox...?

Of course, since your code doesn't compile "as is" (the missing "void"), I
wonder if the real problem has been left in the /real/ code, and not posted
in the sample?

Marc

 

[Jon Skeet [C# MVP]]

It works just fine for me... what are you expecting? And what version of
.NET are you using?

Load happens as the form is preparing to display (i.e. during ShowDialog,
not during the constructor); this throws your exception, which is shown via
the MessageBox...?

Of course, since your code doesn't compile "as is" (the missing "void"), I
wonder if the real problem has been left in the /real/ code, and not posted
in the sample?

On my machine it's not shown in the deliberate (clean) message box -
it's shown as a nasty ".NET has failed" error. Not entirely sure what's
going on there, but it may be due to ShowDialog being shown from a non-
UI thread.

 

[Marc Gravell]

Very curious!

Could try adding an [STAThread]; also might depend on the OS; I'm using XP /
x86; tested fine via 2008 team and express.

Marc

 

[Jacek Jurkowski]

Messagebox isn't shown with OnLoad but it
works fine with OnShown. Its a problem for me because
i used to do some actions in OnLoad and if some of that
actions go wrong i have no any exception message any more.

Vs.Net 2008 NetFramework 3.5

Here is a code:

using System;
using System.Collections.Generic;
using System.Linq;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
static class Program
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main()
{
Application.EnableVisualStyles();
Application.SetCompatibleTextRenderingDefault(false);

try
{
Form1 f = new Form1();
Application.Run(f);
}
catch (Exception c)
{
MessageBox.Show(c.Message);
}
}
}
}


using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using System.Windows.Forms;

namespace WindowsFormsApplication1
{
public partial class Form1 : Form
{
public Form1()
{
InitializeComponent();
}
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);

throw new Exception("sjhsjshsj");
}

protected override void OnShown(EventArgs e)
{
base.OnShown(e);

//throw new Exception("sjhsjshsj");
}
}
}

 

[Jon Skeet [C# MVP]]

Very curious!

Could try adding an [STAThread]; also might depend on the OS; I'm using XP /
x86; tested fine via 2008 team and express.

Vista, running from a console. Adding [STAThread] makes no odds, nor
does compiling as a Windows Forms app instead of a console app.

It then shows the form, by the way...

 

[Marc Gravell]

Actually I lied - it works with a debugger attached, but not standalone. The
worst type of bug... I'll keep looking...

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Why in thet case "throw" doesn't work?
There is no exception rising and there should
be!

Are you saying there is no error at all?

Do you get the form displayed?

 

[Jacek Jurkowski]

B.T.W

On many form on my application i must do
some actions on startup. F.e. i have to fill
a list of clients or a products. I used to put that
code in OnLoad of the form mainly. Where do you do
such actions mostly?

 

[Jacek Jurkowski]

No error, no window at all ...

 

[Marc Gravell]

Interesting...

First: if I subscribe to Application.ThreadException, then the behavior is
identical with/without debugger.

Second: with the debugger, the stack-trace goes all the way back to Main();
without the debugger, the stack-trace only goes back as far as
NativeWindow.Callback [even though ManagedThreadId is the same], which
explains why it is considered unhandled, and why it appears as a
ThreadException.

Actually sounds similar to something I was looking at the other day where
the principal evaporated for the duration of an async callback /
Control.Invoke, but was there (again: on the same ManagedThreadId)
subsequently...

Marc