Close a form from it's constructor ?

[JezB]

How can I close a form (or stop it from opening, thus returning control to
its caller) from it's constructor ?

I've tried both the following but they just seem to carry on and open the
form.

Application.Exit();
this.Close();

 

[Herfried K. Wagner [MVP]]

How can I close a form (or stop it from opening, thus returning control to
its caller) from it's constructor ?

I've tried both the following but they just seem to carry on and open the
form.

Executing a form's constructor doesn't necessarily show the form. You could
throw an exception to indicate that constructing the instance didn't
successfully complete.

 

[FUnky]

Executing a form's constructor doesn't necessarily show the form. You

could throw an exception to indicate that constructing the instance didn't
successfully complete.

or else you could call this.Close() in the form_load event.

 

[Herfried K. Wagner [MVP]]

or else you could call this.Close() in the form_load event.

Yep, but why show the form at all if you do not want it to be shown? I
believe that the constructor is a more suitable place for performing these
checks.

 

[Stoitcho Goutsev \(100\)]

Throwing exception form the form constructor will prevent the from from
showing. Hoewever I personally believe that throwing exceptions from
constructors is a bad idea. Further more exceptions should be used for
exceptional situations - something that is not expected. If you check a
condition and this is a part of the normal process flow I wouldn't call this
an exceptional situation, so I give my vote to using the Load event and
closing the form from there.

 

[Nick Hounsome]

Throwing exception form the form constructor will prevent the from from
showing. Hoewever I personally believe that throwing exceptions from
constructors is a bad idea.
Why?

Further more exceptions should be used for exceptional situations -
something that is not expected.

So you think that it is normal to create an object and then decide that you
didn't want it after all and throw it away without using it? Doesn't strike
me as a good way to program!

If you check a condition and this is a part of the normal process flow I
wouldn't call this an exceptional situation> , so I give my vote to using
the Load event and closing the form from there.

I couldn't disagree more strongly.

 

[Patrice]

As you can see from the controversial answers you raised, you may want to
explain what you are trying to do exactly.

My first move would to avoid opening the form at all, rather than to open
the form just so that it can then see there is no need to open...

 

[Stoitcho Goutsev \(100\)]

Nick,

You have right to disagree. That's why I said that this is my personal
opinion.

I'd say it is not common for code to catch *new* statement in a try/catch
and that almost no one check the docs if the constructor throws an
exception.

 

[Nick Hounsome]

Nick,

You have right to disagree. That's why I said that this is my personal
opinion.

Very reasonable of you. I'm not that reasonable - I think that I'm right and
you're wrong

I'd say it is not common for code to catch *new* statement in a try/catch
and that almost no one check the docs if the constructor throws an
exception.

It is not common because most ctors don't normally throw but the it is not
common to call most methods in a try/catch block either for the same reason
so what's your point?

People will check the throw spec of any method or constructor that they
think will perform checks that might fail or that allocates resources.

One thing that nobody EVER checks is whether or not the form that they just
told to show itself actualy did so. One of the reasons that exceptions are
the foundation of error reporting in modern langauges rather than return
codes or statuses is that experience has shown that nobody ever checks
those.

You are also arguing against yourself in some ways - If it is normal to
throw in the ctor then it will certainly show up in testing and no harm is
done - it is only if it is not normal i.e. exceptional that it might cause a
problem in a deployed app but, as you said, exceptional is exactly what
exceptions are for.

 

[Herfried K. Wagner [MVP]]

You have right to disagree. That's why I said that this is my personal
opinion.

I'd say it is not common for code to catch *new* statement in a try/catch
and that almost no one check the docs if the constructor throws an
exception.

'FileStream' and other stream classes can throw exceptions from the
constructor, as do many other classes. I believe it is less intuitive if
the form's 'Show' method is called and the form doesn't get shown for an
unknown reason.

 

[Stoitcho Goutsev \(100\)]

Herfried,

Streams and others may throw exception because there is an exceptional
situation - the parameters provided is not correct; that is an error that
prevents the object for being created, thus the exceptions is thrown in the
constructor.

This is not always the case though. Most likely the form can be created, but
cannot be shown because some data is missing. In this case the place where
the excepction should be thrown is the moment of showing the form. For
example at the moment of constructing the form some property might not be
set, but it is going to be set later on before showing the form.

I don't think this argument leads anywhere. This are design decisions and I
believe there is no right and wrong. One should use discretion.

 

[JezB]

Simply this: it's doing some validation concerning data that belongs to that
form, that I only want to read when the form is invoked. If validation fails
I want to issue a message and then close the form.

 

[Vlado]

Simply this: it's doing some validation concerning data that belongs to
that form, that I only want to read when the form is invoked. If
validation fails I want to issue a message and then close the form.

You could do something like this:

YourForm yf = new YourForm();
if (yf.SomeMethodThatDoesValidation())
{
yf.Show();
}
else
{
this.DoSomethingElseInsteadShowingYourForm();
}

HTH

 

[Patrice]

As you create the form, you take those data from somewhere else ? Can't you
take them from the same location without invoking the form so that you can
test if you need to show or not this form.

It would seem cleaner to me than to create a form that would retrieve some
data in its constructor and would then kill itself based on some test...

Other options :
- You should be able to create the form without showing it. Some code may
help to understand what goes wrong...
- You could perhaps use DialogResult in the constructor and close the form
in the load event if the DialogResult has the "cancelled" value

 

[Marc Gravell]

Well, in the ctor, it hasn't yet been opened or shown, so there isn't much
to close; you could through an exception?

Marc