UserControl - If I throw, who catches?

[Larry D. Leach]

If a WinForms UserControl throws an exception, where can this be caught on
the form containing the UserControl?

[Jonathan Allen]

You need to be more specific. A UserControl can't just throw an exception,
it has to be in response to an event or method call. In which case the
thread calling the method has to deal with the problem.

--
Jonathan Allen


"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
news:3ad74cae$1@news.devx.com...
>
> If a WinForms UserControl throws an exception, where can this be caught on
> the form containing the UserControl?

[Rob Teixeira]

Usercontrols don't throw errors out of the blue.
The exception will be caught by whatever function invoked the usercontrol
method that throws the exception. For example:

I have a method called Save on my TextFileWidget usercontrol.
A user drags TextFileWidget1 onto the form.
In a button click handler procedure he types:

Private Sub Button1_Click(...) Handles Button1.Click
TextFileWidget1.Save("C:\myfile.dat")
End Sub

In the Save code you write in the usercontrol, you decide to throw an ExtensionNotValid
exception. The user's Button1_Click function will catch it (actually, he's
not catching any exception in this sample, but that's where it goes).

-Rob

"Larry D. Leach" <Larry@ldlsoftware.com> wrote:
>
>If a WinForms UserControl throws an exception, where can this be caught
on
>the form containing the UserControl?

[Larry D. Leach]

Sorry. To be more specific, I have an address control (city/state/zip, etc.).
In the OnLeave event of the control, I call a validation routine. Within
that routine, I want to build and throw custom exceptions for what are basically
business rule violations.

Is SEH even the right way to approach this?

Thanks,

-ldl-

"Jonathan Allen" <greywolf@cts.com> wrote:
>You need to be more specific. A UserControl can't just throw an exception,
>it has to be in response to an event or method call. In which case the
>thread calling the method has to deal with the problem.
>
>--
>Jonathan Allen
>
>
>"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
>news:3ad74cae$1@news.devx.com...
>>
>> If a WinForms UserControl throws an exception, where can this be caught
on
>> the form containing the UserControl?
>
>

[Patrick Steele]

In article <3ad75894$1@news.devx.com> (from Larry D. Leach
<Larry@ldlsoftware.com>),
>
> Sorry. To be more specific, I have an address control (city/state/zip, etc.).
> In the OnLeave event of the control, I call a validation routine. Within
> that routine, I want to build and throw custom exceptions for what are basically
> business rule violations.
>
> Is SEH even the right way to approach this?

Why not just raise an event with an error code?

--
Patrick Steele
(psteele@ipdsolution.com)
Lead Software Architect
Image Process Design

[Jonathan Allen]

> Is SEH even the right way to approach this?

No, you never want to throw an exception in response to an event.

I think you should have a IsValid property that returns true if the data is
valid. This property can be checked when the user hit's Ok on the form. If
there is a problem, then a normal message box can be displayed altering the
user.

--
Jonathan Allen


"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
news:3ad75894$1@news.devx.com...
>
> Sorry. To be more specific, I have an address control (city/state/zip,
etc.).
> In the OnLeave event of the control, I call a validation routine. Within
> that routine, I want to build and throw custom exceptions for what are
basically
> business rule violations.
>
> Is SEH even the right way to approach this?
>
> Thanks,
>
> -ldl-
>
> "Jonathan Allen" <greywolf@cts.com> wrote:
> >You need to be more specific. A UserControl can't just throw an
exception,
> >it has to be in response to an event or method call. In which case the
> >thread calling the method has to deal with the problem.
> >
> >--
> >Jonathan Allen
> >
> >
> >"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
> >news:3ad74cae$1@news.devx.com...
> >>
> >> If a WinForms UserControl throws an exception, where can this be caught
> on
> >> the form containing the UserControl?
> >
> >
>

[Larry D. Leach]

Hmmm... Good thought. I have already built a custom exception class that
can hold many errors (e.g., in this case, invalid zip code format, missing
required fields, etc.). However, rather than throwing it, I just pass it
in the event. I like it.

One more question, if I may. How do I include the same class definition
(my custom exception class) in different projects and have it seen as the
'same' definition. Do I need to place that definition in a DLL and then
reference the DLL from the other projects?

Thanks much,

-ldl-

Patrick Steele <psteele@ipdsolution.com_> wrote:
>In article <3ad75894$1@news.devx.com> (from Larry D. Leach
><Larry@ldlsoftware.com>),
>>
>> Sorry. To be more specific, I have an address control (city/state/zip,
etc.).
>> In the OnLeave event of the control, I call a validation routine. Within
>> that routine, I want to build and throw custom exceptions for what are
basically
>> business rule violations.
>>
>> Is SEH even the right way to approach this?
>
>Why not just raise an event with an error code?
>
>--
>Patrick Steele
>(psteele@ipdsolution.com)
>Lead Software Architect
>Image Process Design

[Larry D. Leach]

Thanks Jonathan,

>No, you never want to throw an exception in response to an event.

Is that a pretty standard sentiment for using exceptions? Does it cause
a problem, or is it just considered poor programming?

Part of what I want to do is provide descriptions of all errors found to
the parent form, so a simple property won't give me what I'm after.

And btw, I think I would get in trouble if I tried to alter the user <g>.


"Jonathan Allen" <greywolf@cts.com> wrote:
>> Is SEH even the right way to approach this?
>
>No, you never want to throw an exception in response to an event.
>
>I think you should have a IsValid property that returns true if the data
is
>valid. This property can be checked when the user hit's Ok on the form.
If
>there is a problem, then a normal message box can be displayed altering
the
>user.
>
>--
>Jonathan Allen
>
>
>"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
>news:3ad75894$1@news.devx.com...
>>
>> Sorry. To be more specific, I have an address control (city/state/zip,
>etc.).
>> In the OnLeave event of the control, I call a validation routine. Within
>> that routine, I want to build and throw custom exceptions for what are
>basically
>> business rule violations.
>>
>> Is SEH even the right way to approach this?
>>
>> Thanks,
>>
>> -ldl-
>>
>> "Jonathan Allen" <greywolf@cts.com> wrote:
>> >You need to be more specific. A UserControl can't just throw an
>exception,
>> >it has to be in response to an event or method call. In which case the
>> >thread calling the method has to deal with the problem.
>> >
>> >--
>> >Jonathan Allen
>> >
>> >
>> >"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
>> >news:3ad74cae$1@news.devx.com...
>> >>
>> >> If a WinForms UserControl throws an exception, where can this be caught
>> on
>> >> the form containing the UserControl?
>> >
>> >
>>
>
>

[Larry D. Leach]

Ugh. Dumb question. I guess a custom exception object is not a good way
to handle this (but it should be easy to devise a good solution for this
specific situation using an event).

However, I'm still in a quandry about how to develop a good overall framework
for error handling in a large WinForms project. Any input from you .Net
pros out there is welcome.

Thanks,

-ldl-

"Larry D. Leach" <Larry@ldlsoftware.com> wrote:
>
>Hmmm... Good thought. I have already built a custom exception class that
>can hold many errors (e.g., in this case, invalid zip code format, missing
>required fields, etc.). However, rather than throwing it, I just pass it
>in the event. I like it.
>
>One more question, if I may. How do I include the same class definition
>(my custom exception class) in different projects and have it seen as the
>'same' definition. Do I need to place that definition in a DLL and then
>reference the DLL from the other projects?
>
>Thanks much,
>
>-ldl-
>
>Patrick Steele <psteele@ipdsolution.com_> wrote:
>>In article <3ad75894$1@news.devx.com> (from Larry D. Leach
>><Larry@ldlsoftware.com>),
>>>
>>> Sorry. To be more specific, I have an address control (city/state/zip,
>etc.).
>>> In the OnLeave event of the control, I call a validation routine. Within
>>> that routine, I want to build and throw custom exceptions for what are
>basically
>>> business rule violations.
>>>
>>> Is SEH even the right way to approach this?
>>
>>Why not just raise an event with an error code?
>>
>>--
>>Patrick Steele
>>(psteele@ipdsolution.com)
>>Lead Software Architect
>>Image Process Design
>

[Gregor R. Peisker]

Hi Larry,

> Is that a pretty standard sentiment for using exceptions? Does it cause
> a problem, or is it just considered poor programming?

If you did this in VB6, Visual Basic would execute an End for you, because
it couldn't pass the error through the event plumbing code (or so it
seemed).

In VB.Net it depends on the code path: Exceptions can be passed on to the
event sender; then, there would be several possibilties:

- The event was raised in response to a message sent by the OS. Does the
sender object use exception handling? If not, your app will terminate.

- The event was raised in response to a method call. Then, the exception is
passed on the another caller, until it finds an exception handler.

So, as I see it, you mostly can't make assumptions about exceptions handlers
being available. If you throw them from a method or property, it's the
callers problem. But events are more like broadcasts to an "anynomous"
audience conceptually; they are more like notifications than calls about
whose results the sender really cares. If you raise an event, you
wouldn't expect your listeners to throw an exception (there can be several
listeners, and if one of them throws an error, what should you do then?).
Therefore, you shouldn't raise exceptions in an event handler (or in an
overridden event-raiser sub, like OnClick).

Regards,
Gregor

[Jonathan Allen]

> >No, you never want to throw an exception in response to an event.
>
> Is that a pretty standard sentiment for using exceptions? Does it cause
> a problem, or is it just considered poor programming?

I think throwing an exception would cause a problem. The severity depends on
the situation, but it is never to generate exceptions in event handlers.

> Part of what I want to do is provide descriptions of all errors found to
> the parent form, so a simple property won't give me what I'm after.

Then use two. One to say there is an error, and another to read what the
error is. The point is that the form gets to decide when to check for
errors, no the control itself.

Consider this...

I am half-way done inputting the address when someone calls me on the phone.
They say they have the account number I need, so I start to input it. Then I
go back and finish the address. Finally, I press Ok, wait a moment while the
page is verified, and then move on to the next screen.

That should be the user experience. From what you were saying, this would
happen...

I am half-way done inputting the address when someone calls me on the phone.
They say they have the account number I need, so I start to input it. The
program has a hissy fit and makes me go back and finish the address. First I
yell at the computer, then I put the person on the phone on hold while I
finish the address. Assuming he didn't hang up, then I put in the broker
account. Finally, I press Ok, and then move on to the next screen.

--
Jonathan Allen


"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
news:3ad764e6@news.devx.com...
>
> Thanks Jonathan,
>
> >No, you never want to throw an exception in response to an event.
>
> Is that a pretty standard sentiment for using exceptions? Does it cause
> a problem, or is it just considered poor programming?
>
> Part of what I want to do is provide descriptions of all errors found to
> the parent form, so a simple property won't give me what I'm after.
>
> And btw, I think I would get in trouble if I tried to alter the user <g>.
>
>

[Larry D. Leach]

Yes, you certainly have a point.

I've switched from throwing an exception to raising an event. The address
control is contained in, and the event is raised in, a base form - meant
to be inherited from. My aim was to take as big a burden off the other programmers
as possible.

What I will change now, is that rather than have the base form display the
errors when the event is raised (in a floating dialog showing all business
rule violations), what I will do is populate some kind of structure that
the end programmer can tap into when the user hits 'save'. This way the
end programmer can truly display all business rule violations, and I've still
encapsulated all the logic for zip code lookup and validation.

Think I'm finally on the right track?

Thanks,

-ldl-


"Jonathan Allen" <greywolf@cts.com> wrote:
>> >No, you never want to throw an exception in response to an event.
>>
>> Is that a pretty standard sentiment for using exceptions? Does it cause
>> a problem, or is it just considered poor programming?
>
>I think throwing an exception would cause a problem. The severity depends
on
>the situation, but it is never to generate exceptions in event handlers.
>
>> Part of what I want to do is provide descriptions of all errors found
to
>> the parent form, so a simple property won't give me what I'm after.
>
>Then use two. One to say there is an error, and another to read what the
>error is. The point is that the form gets to decide when to check for
>errors, no the control itself.
>
>Consider this...
>
>I am half-way done inputting the address when someone calls me on the phone.
>They say they have the account number I need, so I start to input it. Then
I
>go back and finish the address. Finally, I press Ok, wait a moment while
the
>page is verified, and then move on to the next screen.
>
>That should be the user experience. From what you were saying, this would
>happen...
>
>I am half-way done inputting the address when someone calls me on the phone.
>They say they have the account number I need, so I start to input it. The
>program has a hissy fit and makes me go back and finish the address. First
I
>yell at the computer, then I put the person on the phone on hold while I
>finish the address. Assuming he didn't hang up, then I put in the broker
>account. Finally, I press Ok, and then move on to the next screen.
>
>--
>Jonathan Allen
>
>
>"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
>news:3ad764e6@news.devx.com...
>>
>> Thanks Jonathan,
>>
>> >No, you never want to throw an exception in response to an event.
>>
>> Is that a pretty standard sentiment for using exceptions? Does it cause
>> a problem, or is it just considered poor programming?
>>
>> Part of what I want to do is provide descriptions of all errors found
to
>> the parent form, so a simple property won't give me what I'm after.
>>
>> And btw, I think I would get in trouble if I tried to alter the user <g>.
>>
>>
>
>
>

[Kathleen Dollard-Joeris]

Larry,

You might want to add some sort of a problem zone control. Something that
would display the current number of errors and could be clicked by the user
(or hovered over, or whatever) at anytime to see the errors, rather than
waiting until Save is hit.

--
Kathleen
(MS-MVP)
Reply in the newsgroup so everyone can benefit
--

[Jonathan Allen]

I usually have a method called ValidateForm. The Change event of every
control calls this method, which updates any error messages.


--
Jonathan Allen


"Larry D. Leach" <Larry@ldlsoftware.com> wrote in message
news:3ad79637@news.devx.com...
>
> Yes, you certainly have a point.
>
> I've switched from throwing an exception to raising an event. The address
> control is contained in, and the event is raised in, a base form - meant
> to be inherited from. My aim was to take as big a burden off the other
programmers
> as possible.
>
> What I will change now, is that rather than have the base form display the
> errors when the event is raised (in a floating dialog showing all business
> rule violations), what I will do is populate some kind of structure that
> the end programmer can tap into when the user hits 'save'. This way the
> end programmer can truly display all business rule violations, and I've
still
> encapsulated all the logic for zip code lookup and validation.
>
> Think I'm finally on the right track?
>
> Thanks,
>
> -ldl-
>