471,317 Members | 1,339 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,317 software developers and data experts.

Exception not catched in right place


I have situation similar like this.

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

class Class2{
public bool method2(Class3 obj3, DateTime dt){
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?

Feb 24 '06 #1
4 1344

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

*** Sent via Developersdex http://www.developersdex.com ***
Feb 24 '06 #2
Yes I tried that too but no efect.
This weird behavior look me that framework is totaly mess.

Feb 26 '06 #3

<ko****@yahoo.com> wrote in message
news:11**********************@p10g2000cwp.googlegr oups.com...
| 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.

Feb 27 '06 #4
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.

Feb 28 '06 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

10 posts views Thread by Gary.Hu | last post: by
6 posts views Thread by Páll Ólafsson | last post: by
1 post views Thread by Salvador Ponticelli | last post: by
16 posts views Thread by ChInKPoInt [No MCSD] | last post: by
2 posts views Thread by Rajeev Soni | last post: by
5 posts views Thread by Simon Tamman {Uchiha Jax} | last post: by
4 posts views Thread by Paul Czubilinski | last post: by
6 posts views Thread by Mohan | last post: by
4 posts views Thread by michael | last post: by
reply views Thread by rosydwin | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.