exception handling in class library

[Schizoid]

Can someone give me some ideas where I am going wrong? I want to
create a class library that will be used by other programs. In this
library, there is a method to get a list of subdirectories. I want
any exception to return back to the calling program. When I call
this
method, it abends at the point of the exception and does not return
the exception to the calling program:

Calling program:


....
MyObject f = new MyObject();
string[] sf = f.GetSubFolders(@"C:\sadfsfa"); //
directory does not exist


Library:


public class MyObject
{
public string[] GetSubFolders(string location)
{
if (!Directory.Exist(location)
throw new DirectoryNotFoundException(); //
abend
}
}


Why does the program abend at the "throw" line? Shouldn't the throw
return the exception to the calling program?


I also tried changing the GetSubFolders method to use try-catch
statements and it also abends at the trow statement.


thanks

 

[Mufaka]

Are you not catching the exception in the calling program?

 

[Lav]

It's better to put Assert rather than throwing an exception.
An exception can't be RETURNED.They have to be thrown (and
subsequently caught)
I guess you anticipating to get an Exception here..

string[] sf = f.GetSubFolders(@"C:\sadfsfa");

And if you are willing to catch an exception.
Surround it with try catch block.
Hope you are not catching any exception in the GetSubFolders and not
throwing it again..

 

[Mufaka]

I'm not catching anything, nor writing anything. I just asked if he was
catching his exception in the code that was calling his class library.

Can you explain how Assert would help here? It appears that he just
wants to raise a runtime error when a non-existent directory is provided
to his class library. It also appears that he is throwing an exception
correctly but just not checking for it in the calling code.

 

[Jon Skeet [C# MVP]]

It's better to put Assert rather than throwing an exception.

I completely disagree. With assertions:
1) You'd have to take steps to make sure they were in both debug and
release builds
2) You don't get the most appropriate exception

An exception can't be RETURNED.They have to be thrown (and
subsequently caught)

Well, you *can* return exceptions - but I agree that it's rare.

I guess you anticipating to get an Exception here..

string[] sf = f.GetSubFolders(@"C:\sadfsfa");

And if you are willing to catch an exception.
Surround it with try catch block.
Hope you are not catching any exception in the GetSubFolders and not
throwing it again..

 

[Schizoid]

Are you not catching the exception in the calling program?

Hi,

I was not catching the exception in the calling program. I wanted to
test to see if the exception was thrown back to the calling program,
but it was not. The debugger stopped at the throw command in the
class library. Shouldn't the debugger flag the calling statement if I
am throwing an exception in the class library?

thanks

 

[Schizoid]

Hi,

I was not catching the exception in the calling program.  I wanted to
test to see if the exception was thrown back to the calling program,
but it was not.  The debugger stopped at the throw command in the
class library.  Shouldn't the debugger flag the calling statement if I
am throwing an exception in the class library?

thanks

As a test, I did add a try-catch in the calling program and the
program executed correctly.

I guess I am a bit confused about thorwing exceptions. I thought that
if I throw an exception it would move up the stack to the calling
program and bomb there.

If the class library were compiled and provided to others to use, and
the application program did not trap the exception in his/her program,
shouldn't the debugger flag the error in the callin gprogram, and not
the class library?

 

[Jon Skeet [C# MVP]]

As a test, I did add a try-catch in the calling program and the
program executed correctly.

I guess I am a bit confused about thorwing exceptions. I thought that
if I throw an exception it would move up the stack to the calling
program and bomb there.

If the class library were compiled and provided to others to use, and
the application program did not trap the exception in his/her program,
shouldn't the debugger flag the error in the callin gprogram, and not
the class library?

This is just the debugger trying to be helpful. It has the source of
the class library, so it stops as early as it can after the exception
has been thrown, so you can easily see the context.

Try running the code outside the debugger and you'll get the expected
behaviour.

 

[Jeroen Mostert]

As a test, I did add a try-catch in the calling program and the
program executed correctly.

I guess I am a bit confused about thorwing exceptions. I thought that
if I throw an exception it would move up the stack to the calling
program and bomb there.

No. What happens is that the runtime looks for *handlers* by walking the
stack backwards. If one is found, the program continues there. If none is
found, an unhandled exception is reported, terminating the program. The call
stack of that will end in the place where the exception was thrown -- just
as it does when you catch the exception somewhere and print it. The stack
doesn't indicate where the "error" is, just where an exception was thrown.
Where the "error" is (i.e. failure to handle the exception) depends on your
program.

If the class library were compiled and provided to others to use, and
the application program did not trap the exception in his/her program,
shouldn't the debugger flag the error in the callin gprogram, and not
the class library?

No, because you have to apply this argument recursively. Why isn't the error
really in the function calling the function calling the library function?
And so on all the way up to the start of the thread. It is *not* an error
not to handle exceptions from the functions you call, because then it simply
becomes the responsibility of *your* callers. Exceptions do not give you an
error handling strategy for free, nor do they mandate one, except for "catch
the exception somewhere".

The debugger just reports where the exception is *thrown*. It can't report
where it isn't *handled*, because it doesn't know where the proper place to
handle it would be. That's for the programmer to determine.

 

[Schizoid]

The debugger just reports where the exception is *thrown*. It can't report
where it isn't *handled*, because it doesn't know where the proper place to
handle it would be. That's for the programmer to determine.

Thanks to everyone for helping me understand... it's been very
informative.
It kind of makes more sense now.

--john

 

[jehugaleahsa]

This is just the debugger trying to be helpful. It has the source of
the class library, so it stops as early as it can after the exception
has been thrown, so you can easily see the context.

Try running the code outside the debugger and you'll get the expected
behaviour.

This brings up a question I have always had. Is it possible to allow
the debugger to continue after an exception is thrown? It would make
my life easier if I could.

Thanks,
Travis

 

[jehugaleahsa]

This brings up a question I have always had. Is it possible to allow
the debugger to continue after an exception is thrown? It would make
my life easier if I could.

Thanks,
Travis- Hide quoted text -

- Show quoted text -

Uncheck Tools -> Options -> Debugging -> General -> Unwind callstack
on unhandled exception Yay!