exception in constructor

[mp]

I have a class which is responsible to "open and read" a file.
so I have a filename in the constructor of the class
how best to raise exception if filename not valid(or not found)?
//constructor
public cLispFile(string FileName)
{
if (File.Exists(FileName))
{...}
else
{
//what to put here?...raise exception?

throw new Exception("file not found"); //????????????

}
}

thanks
mark

 

[Arne Vajhøj]

I have a class which is responsible to "open and read" a file.
so I have a filename in the constructor of the class
how best to raise exception if filename not valid(or not found)?
//constructor
public cLispFile(string FileName)
{
if (File.Exists(FileName))
{...}
else
{
//what to put here?...raise exception?

throw new Exception("file not found"); //????????????

}
}

Drop File.Exists and simply try to open the file.

In case of failure you should throw an exception.

You should specify the filename in the exception message!

If you moved opening the file from the constructor
to an Open method, then you had the choice between
an exception and the return value.

But exceptions seems fine to me in this
context.

Arne

 

[Registered User]

I have a class which is responsible to "open and read" a file.
so I have a filename in the constructor of the class
how best to raise exception if filename not valid(or not found)?
//constructor
public cLispFile(string FileName)
{
if (File.Exists(FileName))
{...}
else
{
//what to put here?...raise exception?

throw new Exception("file not found"); //????????????

}
}

If the missing file can be created by the cLispFile type, then call
the method that creates the file from the else block. If the file
can't be created by the type, I'd change the c'tor code and just
assume the file exists. If the file doesn't exist let the framework
raise the appropriate exception, a System.IO.FileNotFoundException
IIRC.

regards
A.G.

 

[Jeff Gaines]

In case of failure you should throw an exception.

What about giving the user a chance to specify a different file with a
file open dialog?
From the user's point of view the program has 'crashed' if it throws an
exception, so an opportunity to specify a different file (or correct a
typo) might be appreciated.

 

[Jeff Johnson]

What about giving the user a chance to specify a different file with a
file open dialog?
From the user's point of view the program has 'crashed' if it throws an
exception

Who says he's not trapping the exception upstream? Thrown exceptions !=
crash. UNHANDLED exceptions = crash, mostly.

 

[Jeff Gaines]

Who says he's not trapping the exception upstream? Thrown exceptions !=
crash. UNHANDLED exceptions = crash, mostly.

We don't know of course, but it was worth mentioning I think.

 

[Registered User]

What about giving the user a chance to specify a different file with a
file open dialog?

There are too many unknowns about the type and its intended usage to
speculate.

Even so the time to solicit user input is before calling the c'tor.
Assuming there will be a user to interact with the dialog, what
happens in the c'tor if/when the user clicks the dialog's cancel
button?

I firmly believe that non-UI types should not present any form of UI.
Letting a layer of indirection provide the input and display any
output eliminates any type dependency on both the UI thread and user
interaction.

From the user's point of view the program has 'crashed' if it throws an
exception, so an opportunity to specify a different file (or correct a
typo) might be appreciated.

Ideally the user should never know that an exception has occurred.

regards
A.G.

 

[mp]

If the missing file can be created by the cLispFile type, then call
the method that creates the file from the else block. If the file
can't be created by the type, I'd change the c'tor code and just
assume the file exists. If the file doesn't exist let the framework
raise the appropriate exception, a System.IO.FileNotFoundException
IIRC.

regards
A.G.

thanks to all, Arne, Jeff, Jeff, and Registered User for their inputs
mark

 

[Arne Vajhøj]

What about giving the user a chance to specify a different file with a
file open dialog?

Not from inside the constructor.

From the user's point of view the program has 'crashed' if it throws an
exception, so an opportunity to specify a different file (or correct a
typo) might be appreciated.

Absolutely.

If the constructor throws an appropriate exception then the
controlling code can catch that and prompt for different file.

Arne

 

[Arne Vajhøj]

There are too many unknowns about the type and its intended usage to
speculate.

We can always speculate, but it will just be that.

Even so the time to solicit user input is before calling the c'tor.
Assuming there will be a user to interact with the dialog, what
happens in the c'tor if/when the user clicks the dialog's cancel
button?

Before or in case of exception after.

I firmly believe that non-UI types should not present any form of UI.

Completely agree.

Ideally the user should never know that an exception has occurred.

If fixing the problem requires user action, then it has to be so.

Arne

 

[Zach]

If a dialogue is used to open the file, the user of the application will be
able to see if the fie exists or not, leaving the situation that the file
exists, but that it is empty. Then skip the dialog, enter the file name in
the applicatioon before approaching the open & read class, and check
availability before the class is called.

 

[Arne Vajhøj]

If a dialogue is used to open the file, the user of the application will
be able to see if the fie exists or not, leaving the situation that the
file exists, but that it is empty. Then skip the dialog, enter the file
name in the applicatioon before approaching the open & read class, and
check availability before the class is called.

It will only reduce the risk of the file not existing.

The file could exist when the dialog is open and
disappear before file is actually opened.

Arne

 

[mp]

It will only reduce the risk of the file not existing.

The file could exist when the dialog is open and
disappear before file is actually opened.

Arne

that's also true,
in my case, 99.9999% of the time the file will exist,
(since I happen to plan to use this class to loop through a folder of files
processing each in turn)
..... I just thought i should add the safety factor in case I use it in a
different way in the future and allow for the remote possibility that it
could get
called with a bad filename. (user could type in a filename in a textbox for
example)

I wanted the class to have the responsibility for validating the file,
rather than the calling class to have to do that,
even though in many cases the caller could check the file first,
but if that doesn't happen this is the last backstop.

thanks for everyone's input
mark