StrataFrame Forum » StrataFrame Application Framework - V1 » WinForms (How do I?) » Properly Handling Exception Handling

Properly Handling Exception Handling

Bill Cunnien — Fri, 06 Jun 2008 16:06:53 GMT

Good morning,

I am working through some intricate code and I want to make sure I am made aware of any errors that may pop up at run-time. How I have done this in the past is to create a class that I throw exceptions at and from there send emails or alerts to let me know what is going on. As I understand it there is some exception handling that is already going on within the framework via an error provider. How do I take advantage of that and still provide a streamlined way of handling my exceptions? Also, is this a proper approach to using transactions within my code?

Here is an example of my code that I am trying to work this through:

private void cmdTransfers_Click(object sender, EventArgs e)
{
    try
    {
        // Wrap this entire process in a transaction
        BusinessLayer.TransactionBegin("MyDataSourceName", IsolationLevel.ReadCommitted);

        // Retrieve the next [snip] . . . lots of stuff happening here . . .

       MyLastProcedureToRun(myParm);

        BusinessLayer.TransactionCommit("MyDataSourceName");
    }
    catch (Exception ex)
    {
        // place cool SF exception handling here, if any

        // this is my current way of doing it
        SPXExceptionHandler.ReportException(ex); // exceptions are logged, emailed, etc.
        BusinessLayer.TransactionRollback("Dynamics");
    }
}

Thanks!
Bill

RE: Properly Handling Exception Handling

Greg McGuffey — Fri, 06 Jun 2008 16:06:53 GMT

Very cool! Thanks!

RE: Properly Handling Exception Handling

Trent L. Taylor — Fri, 06 Jun 2008 14:18:31 GMT

[quote]Is this something you've heard of? [/quote]

Thus the credentials. If you supply a mail server, port, and credentials...that's email...period :) We use this everywhere. The only thing that you cannot do is pull mail down from a POP3 server...but sending...no problem :)

RE: Properly Handling Exception Handling

Greg McGuffey — Fri, 06 Jun 2008 11:44:05 GMT

Thanks Trent. I've heard that this can fail because ISPs block mail sent to servers outside of their domain. Is this something you've heard of? I.e. I'm accessing the internet via a wireless connection at a hotel or using the network connection at a client site, attempt to send an email via the SMTP server at my company and the hosting network blocks the email.

RE: Properly Handling Exception Handling

Trent L. Taylor — Fri, 06 Jun 2008 08:42:08 GMT

.NET actually has some good SMTP classes for sending emails. Here is a simple example (I went ahead and showed how to authenticate as this is generally the next question. If you are mailing from an internal server that will relay your message you might not need this, but I thought it would help. Also, you can format the mail message to support HTML, etc. I just showed you the basics.

[codesnippet]Dim smtp As New System.Net.Mail.SmtpClient("mymail.server.com")
Dim mailItem As New System.Net.Mail.MailMessage("myEmail@somewhere.com", _
                                                "someone@there.com", _
                                                "Howdy", _
                                                "Here is the body")

smtp.Credentials = New System.Net.NetworkCredential("MyUserName", "MyPassword")
smtp.Send(mailItem)[/codesnippet]

RE: Properly Handling Exception Handling

Greg McGuffey — Thu, 05 Jun 2008 13:01:19 GMT

Oh, how did you send the email? I've been thinking about doing this also, and am investigating ways of doing it.

RE: Properly Handling Exception Handling

Greg McGuffey — Thu, 05 Jun 2008 13:00:17 GMT

Cool!

One thing to note is that I used the using statement. It closes the form when done (when the using code block is done). If you don't use this, then you should close the form after you are done with it. The form is still open otherwise.

RE: Properly Handling Exception Handling

Bill Cunnien — Thu, 05 Jun 2008 12:56:05 GMT

Yup...I think we met the same conclusion at about the same time. Here is what I did:

Set a public variable in the dialog form (Form2):

public String _userinfo;

On the cmdOK_Click event, I set the value of the comments textedit control to the public variable.

Then, on Form1, within the deep inner workings of the unhandled exception routine:

MyExceptionData mNewForm = new MyExceptionData(e.UnhandledException);
mNewForm.ShowDialog();
mUserData = mNewForm._userinfo;

I am passing the exception to the form because I am formatting the exception data on the form for my own (or other savvy users') review.

So far, so good...thanks a ton for your help!!
Bill

RE: Properly Handling Exception Handling

Greg McGuffey — Thu, 05 Jun 2008 12:44:19 GMT

I'd open the form as a dialog (ShowDialog method), then access properties on the form to get the info from the form. Code would be something like this (my C# is a bit rusty...hopefully this gets the idea across):
[codesnippet]// UserErrorDialog is form that collects info from user
String userInfo = String.Empty;
using ( UserErrorDialog form = new UserErrorDialog())
{
// Show the form as a dialog, which will wait for user to close the form
if (form.ShowDialog()== DialogReslut.OK)
{
// Get user info from properties on form
userInfo = form.UserInfo
}
}

// Send email, display dialog whatever...[/codesnippet]

Hope that helps!

RE: Properly Handling Exception Handling

Bill Cunnien — Thu, 05 Jun 2008 12:23:41 GMT

#1 is solved by properly referencing the namespace.

That happens way too often for comfort . . . bah! foiled again!

For the moment, the second need still eludes me.

Curse you, Aqua-Scum!
Bill

RE: Properly Handling Exception Handling

Bill Cunnien — Thu, 05 Jun 2008 12:17:22 GMT

Ok...I am now attempting to catch all unhandled exception in the program.cs. What I want to do is popup a nice message telling the user that a bad thing has just happened and that the IT department has been sent an email. This works. The email gets delivered. In addition to the nice message, I want to open a dialog window that will allow the user to enter any information that they would like to help explain what they were doing at the time of the error. Once filled in, the dialog closes and adds that info to the body of the email before sending.

I am having two problems:

1) The form that I created for doing this is not accessible by the code in program.cs.

2) The string variable cannot be fed back to the program.cs routine.

Thought?
Bill

RE: Properly Handling Exception Handling

Greg McGuffey — Wed, 04 Jun 2008 16:08:11 GMT

Well, when you say it like that, it is all so clear now :blink:

But it is exactly right! :cool:

RE: Properly Handling Exception Handling

Bill Cunnien — Wed, 04 Jun 2008 15:31:02 GMT

Thanks, Greg!

So, placing a throw after the rollback will force the handled exception to be an unhandled exception which will actually be handled by the program.cs unhandled exception handler?

Right?

:smooooth:

RE: Properly Handling Exception Handling

Trent L. Taylor — Wed, 04 Jun 2008 13:22:28 GMT

Well said, Greg ;)

RE: Properly Handling Exception Handling

Greg McGuffey — Wed, 04 Jun 2008 11:25:27 GMT

Bill,

It is actually way easier than this. There is an application event handler in program.cs (appmain.vb) that is for unhandled exceptions. You'd put your SPXExceptionHandler.ReportException(ex); call in there and indicate through the event hards that you've handled it. Now any unhandled exception is handled by this code...every where.

Now in the case of using a try/catch, so you can do the rollback, you'd still want to handle that, but after you do the rollback, you'd rethrow the exception. You could even wrap the original exception in one specific to that situation.
[codesnippet]private void cmdTransfers_Click(object sender, EventArgs e)
{
try
{
// Wrap this entire process in a transaction
BusinessLayer.TransactionBegin("MyDataSourceName", IsolationLevel.ReadCommitted);

// Retrieve the next [snip] . . . lots of stuff happening here . . .

MyLastProcedureToRun(myParm);

BusinessLayer.TransactionCommit("MyDataSourceName");
}
catch (Exception ex)
{
BusinessLayer.TransactionRollback("Dynamics");

// rethrow the original exception now that rollback is complete
Throw
}
}[/codesnippet]
Note that the procedure is only responsible for throwing the exception, not dealing with it...that is done in the application unhandled exception handler!

Hope that makes sense!