Exception not catched in right place

[koltti]

Hello,

I have situation similar like this.

class Class1{
private Class2 obj2;
...
public bool method1(Class3 ob3j, DateTime dt){
try{
obj2.Method2(obj3, dt);
}
catch(Exception e) {
Console.WriteLine(e.ToString())
}
}
}

class Class2{
public bool method2(Class3 obj3, DateTime dt){
try{
Console.WriteLine("Class2,method2");
...
}
catch{
return false;
}
return true;
}

When I call method1 from COM client. Sometimes I got excepion from
method2 but it not catched in method2. It will catched in method1 and
exception says that it happen in method2. Exception is "Arithmetic
operation resulted in an overflow".
What could be a reason that exception is not catched in method2?

 

[Brian]

I haven't experienced this myself, but have you tried adding
catch(Exception ex) to method2?


BugSentry needs beta testers!
www.bugsentry.com

 

[koltti]

Yes I tried that too but no efect.
This weird behavior look me that framework is totaly mess.

 

[Willy Denoyette [MVP]]

| Yes I tried that too but no efect.
| This weird behavior look me that framework is totaly mess.
|

Post a small but complete sample that illustrates the issue.

Willy.

 

[Bruce Wood]

I'm not familiar with what happens in the case of COM, but I know that
the way that exceptions work can sometimes be counterintuitive when
dealing with Windows Forms.

Remember that not all calls happen when you think they do. Of course, a
direct call like the one shown in the code sample will happen when you
expect it to, and the exceptions should work the way that you expect
them to, but I don't know what will happen when you venture into the
world of COM.

In WinForms, calls to event handlers (such as button press handlers)
are often queued on the event queue and then later called directly from
the WinForms base event loop (sorry for murdering the terminology...
). So, what looks like a straightforward call to an event handler ends
up being queued and handled later, and so exceptions within that call
don't bubble back "up" to what appears to be the event origin, because
the event origin queued the event and then long ago exited, so you get
stack dumps that show your method being called directly from the
runtime, rather than from whence you thought it would be called.

That's a good question here: what does the stack dump on the exception
look like? Is the method being called from where you thought it was
being called?

Tens of thousands of programmers are using the .NET Framework to do all
sorts of things. While there may be a (few) bugs, and some of the
Framework's behaviour may not make sense until you investigate it
further, I have a hard time believing that our lack of understanding
makes the whole thing a writeoff, or a "mess" as you put it.