First of all, never do it in the constructor. Defer this part if initialization until the moment when the main event handling cycle of the application is already working, for example, when the main window is already shown. This way, the mechanism of catching of all of the exception in the main UI loop can be used.
If this file reading and processing procedure can also get some considerable time, do it in even more accurate way: do it in the separate thread.
This might be not the real reason of the hanging you observe. You need to execute your code under debugger to be sure.
[EDIT #1]
Also, there are no situations where a hard-coded path like your "/Mall_List/Mall_List.txt" could be useful, no matter if this is a relative or absolute path. Now your code depends on working directory, and this directory can be anywhere at all; it's defined by the user, how an application is started.
The file can be found relative to the executable directory, or "special folder" (
System.Environment.GetFolderPath
,
http://msdn.microsoft.com/en-us/library/system.environment.getfolderpath.aspx[
]), or calculated based on some configuration data — never hard-coded.
[EDIT #2: following up the discussion in the comments to this question]
I looks like you mix up
working directory and
executable directory. The working directory has nothing to do with the directory where your executable files are — it is defined be the user and can be anywhere. This is a parameter in a .LNK file; and if started directly, is still defined by the user. Most usually, this is the current working directory of some other program, like a file manager (Explorer or any other) at the moment when the user starts the application. So, it can be anywhere; and your program can change it. When you use a relative path, the actual path is found relative to the current working directory, which can be anything. This approach is often used in console applications, where a more experienced user directly controls the working directory and know where to provide and expect files.
The directory where your executable files are, in contrast, never changes unless you move those executable files and start the application again. Here is how to find it:
string location = System.Reflection.Assembly.GetEntryAssembly().Location;
string executableDirectory = System.IO.Path.GetDirectoryName(location);
Please pay attention, that this is a reliable method; there are other methods which can give you confusing results in some more special cases, but this will work the same way in all cases. I explain it in some more detail here:
How to find my programs directory [
(executable directory) ].
And I advised in the working directory and "special folder" here:
How to find my programs directory [
(current directory and "special folder") ].
I think now you should have comprehensive information on the directory issues.
—SA