Newbie Question on Error Handling

  • Thread starter Thread starter Figmo
  • Start date Start date
F

Figmo

I'm new to C# and I have a question on how the debugger handles various
errors.

A) Sometimes - I get an error and the debugger breaks on the line with
the error so I can take a look at it. And it gives me a nice error
message on why it didn't like this line of code.

B) Sometimes - I get an error and it will not take me to the debugger -
instead I receive a message box with error info and a section saying
that I need to enable JIT debugging. I have tried to follow the
included directions but I always get this message box for this type of
error.

C) The wierd one: sometimes - I get an error and the method just exits
without reporting anything. I can step through it line by line with
the debugger and when I step over the offending line of code - the
function just returns. No error message. This is perhaps the
strangest of the 3 scenarios. The first 2 I can handle no problem -
but I just can't understand how the compiler can just bail out of a
function without throwing an exception or otherwise alerting me that
something bad happened. Usually - this is when I'm calling a method of
some component and passed it some invalid data. I can see the problem
if I look hard enough - but I'm stunned that I received no error
message.

Just curious - why the lack of consistency?
 
are you using try catch finally?

use try catch to catch exceptions. If you add a message box such as this

try
{
some code
}
catch(Exception ex)
{
MessageBox.Show(ex.Message); //this will show a message box when there
is an exception caught.
//you can also get stacktrace and other items, see Exceptions on msdn.
}
finally //not necessary to implement but do so if you need to clean up
resources etc.
{
}

Scenario 1. If you use predefined classes then there are exception handlers
provided by microsoft programmers therefore you see the
messagebox and line numbers etc.

Scenario 2. This must have to do with things such as stackoverflow or
divide by zero or such errors (exceptions) which are not caught by CLR or
your code. This may be internally generated exceptions.

Scenario 3. This must be your code where you have not used try catch blocks
to trap the exception(s). Therfore it does not show message but just
crashses.


its the lack of consistency on your part. You should read up on the try
catch tutorial on msdn it helps. Most of us have done it :).

gl
 
Raj,

I know about try...catch

My question wasn't how can I programatically catch exceptions - it was
more about why the native C# environment - in the total absence of any
of my own exception/error handling - behaves differently.

Let's focus on scenario 3 - since the first 2 are really not a big deal
- I am alerted to these errors and can fix my code to either not
generate them, or catch the exceptions and handle them gracefully.
Plus, your explanation of these 2 scenarios makes sense to me.

It's the 3rd one that has me puzzled. I call a method from a component
- pass it invalid data - and my function just exits. No unhandled
exception errors. No break in the debugger. No nothing. Just
returns. Like I issued a return statement. (I do NOT have any
try...catch in place to handle exceptions)


Here's some pseudo code

public formCustomer() {
InitializeComponent();
3rdPartyComponent component = new 3rdPartyComponent();
m_var1 = component.ProcessThis("Invalid Data"); //...offending code
m_var2 = component.ProcessThis("Valid Data); //...never gets here
- but no errors reported
}

Could it be because the offending code is in the constructor of one my
classes? I am wondering why C# just bails out of the constructor
without reporting ANY sort of error or exception when it encounters
this error.


-Figmo
 
Figmo said:
Here's some pseudo code

public formCustomer() {
InitializeComponent();
3rdPartyComponent component = new 3rdPartyComponent();
m_var1 = component.ProcessThis("Invalid Data"); //...offending code
m_var2 = component.ProcessThis("Valid Data); //...never gets here
- but no errors reported
}

Could it be because the offending code is in the constructor of one my
classes? I am wondering why C# just bails out of the constructor
without reporting ANY sort of error or exception when it encounters
this error.

No, it's not because it's in a constructor. Unfortunately, without a
complete example it's impossible to say what's going on.

Could you post a short but complete program which demonstrates the
problem?

See http://www.pobox.com/~skeet/csharp/complete.html for details of
what I mean by that.
 
I know what you saying, i have had the same problem with my designer. One of
my control had a bug this bug was comming from.... i wish i had a clue...
but nonetheless i put that code in a try catch block and added a messagebox
in the catch statement and all i got was object not set to ref of and
object...error i tried to trace in many ways but i could not so i went with
the taking the msg box and leaving the try and catch block.



here is where i had the problem

try

{

AppSettings app = new
AppSettings(((Assembly.GetEntryAssembly()).GetName()).Name+".exe.config");

string themeDirectory =
app.GetValue("//appSettings//add[@key='themedirectory']");

Bitmap bit = null;

for(int i = 0; i < dialPadImagenames.Length; i++)

{

bit = new
Bitmap(Application.StartupPath+"\\skins\\"+themeDirectory+"\\dialpad\\"+dialPadImagenames);

dialPadImages.Add(bit);

System.Diagnostics.Debug.WriteLine(Application.StartupPath+"\\skins\\"+themeDirectory+"\\dialpad\\"+dialPadImagenames);

}

}

catch{}

finally

{

dialPadPictures.Add(picDialPound);

:

}



i do agree with what you are saying that their is a inconsistency in
designer and alot of the classes related to exception handling :)
 
Hard to post "short but complete program" for this since it coming from
a 3rd party component that you most likely do not have. And I don't
have the source to the component to see how the error is occuring to
try and re-create the original error on my own from a test program.

I agree that it's nothing to do with the constructor because it just
happened to me again from another function. It's wierd because it
seems to exit ALL THE WAY back from the call stack. In other words - I
have MethodA() that calls MethodB() and the error happens in MethodB().
But if I put a breakpoint on the line in MethodA() after the call to
MethodB() - I never get there either. So it's exiting not only out of
MethodB(), but also out of MethodA() - all without giving me any
indication of this or hitting any other lines of my code within my
program.

Oh well - I guess I'll just chalk this one up in my brain as
"undocumented program behavior" on the part of VS.NET. It's not the
end of the world. Just a little frustrating when I encounter this.
 
Figmo said:
Hard to post "short but complete program" for this since it coming from
a 3rd party component that you most likely do not have. And I don't
have the source to the component to see how the error is occuring to
try and re-create the original error on my own from a test program.

I agree that it's nothing to do with the constructor because it just
happened to me again from another function. It's wierd because it
seems to exit ALL THE WAY back from the call stack. In other words - I
have MethodA() that calls MethodB() and the error happens in MethodB().
But if I put a breakpoint on the line in MethodA() after the call to
MethodB() - I never get there either. So it's exiting not only out of
MethodB(), but also out of MethodA() - all without giving me any
indication of this or hitting any other lines of my code within my
program.

Oh well - I guess I'll just chalk this one up in my brain as
"undocumented program behavior" on the part of VS.NET. It's not the
end of the world. Just a little frustrating when I encounter this.

It sounds to me like an exception is being thrown, you're just not
being able to catch it.
 
Try setting the debugger to break on first chance exceptions....if the cause
is that an exception is getting thrown that the code is not catching this
will at least break at its occurrence, even if it occurs in 3rd party code.
It will also break in the context of the thread where the exception was
thrown.

Figmo said:
Hard to post "short but complete program" for this since it coming from
a 3rd party component that you most likely do not have. And I don't
have the source to the component to see how the error is occuring to
try and re-create the original error on my own from a test program.

I agree that it's nothing to do with the constructor because it just
happened to me again from another function. It's wierd because it
seems to exit ALL THE WAY back from the call stack. In other words - I
have MethodA() that calls MethodB() and the error happens in MethodB().
But if I put a breakpoint on the line in MethodA() after the call to
MethodB() - I never get there either. So it's exiting not only out of
MethodB(), but also out of MethodA() - all without giving me any
indication of this or hitting any other lines of my code within my
program.

Oh well - I guess I'll just chalk this one up in my brain as
"undocumented program behavior" on the part of VS.NET. It's not the
end of the world. Just a little frustrating when I encounter this.
 
Could it be that the exception is being thrown from another thread? I
just had this problem, where from within a try block I called a method,
and in that method I dilberatly threw an exception - and the try block
didn't catch it. The ng response was that the exception was being
thrown in a diff tread and so that thread just died.

Could it be the same/similar thing here?

--Brian
 
Brian Pelton said:
Could it be that the exception is being thrown from another thread?

That wouldn't stop the current thread of executing.
I just had this problem, where from within a try block I called a method,
and in that method I dilberatly threw an exception - and the try block
didn't catch it. The ng response was that the exception was being
thrown in a diff tread and so that thread just died.

Could it be the same/similar thing here?

I'd have to see the code in question, but it doesn't sound like that's
what's happening here.
 
Back
Top