exception in constructor

  • Thread starter Thread starter mp
  • Start date Start date
M

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
 
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"); //????????????

}
}
Click to expand...

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
 
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"); //????????????

}
}
Click to expand...

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.
 
In case of failure you should throw an exception.
Click to expand...

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.
 
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
Click to expand...

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

We don't know of course, but it was worth mentioning I think.
 
What about giving the user a chance to specify a different file with a
file open dialog?
Click to expand...

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.
Click to expand...

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

regards
A.G.
 
Registered User said:
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.
Click to expand...

thanks to all, Arne, Jeff, Jeff, and Registered User for their inputs
mark
 
What about giving the user a chance to specify a different file with a
file open dialog?
Click to expand...

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.
Click to expand...

Absolutely.

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

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

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?
Click to expand...

Before or in case of exception after.
I firmly believe that non-UI types should not present any form of UI.
Click to expand...

Completely agree.
Ideally the user should never know that an exception has occurred.
Click to expand...

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

Arne
 
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.
 
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.
Click to expand...

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
 
Arne Vajhøj said:
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
Click to expand...

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
 
Back
Top