Hi guys,

Long ago, I learned that it was a bad idea to throw exceptions inside a
constructor. For instance:

Public Class OutCountMovementArgs

    Private innerDirection As OutCountDirection
    Private innerStartDate As Date
    Private innerEndDate As Date

    Public Sub New(ByVal direction As OutCountDirection, _
        ByVal startDate As Date, _
        ByVal endDate As Date)

        If startDate < #10/1/2004# Or startDate > Today Then
            Throw New DateOutOfRangeException("startDate")
        End If

        If endDate < #10/1/2004# Or endDate > Today Then
            Throw New DateOutOfRangeException("endDate")
        End If

        If startDate > endDate Then
            Throw New DateRangeOutOfOrderException
        End If

        innerDirection = direction
        innerStartDate = startDate
        innerEndDate = endDate

    End Sub

    Public ReadOnly Property Direction As OutCountDirection
        Get
            Return innerDirection
        End Get
    End Property

    Public ReadOnly Property StartDate As Date
        Get
            Return innerStartDate
        End Get
    End Property

    Public ReadOnly Property EndDate As Date
        Get
            Return innerEndDate
        End Get
    End Property

End Class

Is this still considered a bad idea? My gut tells me that it is, as a
lot of users tend to write variable initialization code outside of
Try-Catch blocks, like this:

    Dim myStartDate As Date
    Dim myEndDate As Date = Today
    Dim args As New OutCountArgs(OutCountDirection.Into, myStartDate,
myEndDate)

    Try
        .
        .
        .
    Catch...
    End Try

The example above will fail (because myStartDate defaults to 1/1/1900),
resulting in a DateOutOfRangeException which isn't caught by the
Try...Catch handler, and surprises the developer. I, myself, try to
avoid that, but occasionally get caught by it myself. To code the class
the other way makes for very wordy code because you have to to
explicitly initialize every property (although that tends to be very
clear).

In general, how do you handle this? My inclination is to err on the
side of caution. I'm coding in a vaccuum here (only developer in the
entire company now for 2 years), so I have no one with whom to discuss
these kinds of issues, and I'm a little out of touch with the
community.

Any input is greatly appreciated!

Mike Hofer wrote:
Indicating an error from a constructor is one of the main reasons that
modern langauges have exceptions in the first place.  It's not a bad idea to
throw from a constructor if it's not possible to construct a valid object
(due to invalid parameters or any other factors).

[ example snipped for brevity ]

It shouldn't surprise a .NET developer.  The better structure is this:

    Try
        Dim myStartDate As Date
        Dim myEndDate As Date = Today
        Dim args As New OutCountArgs(OutCountDirection.Into, myStartDate,
            myEndDate)
        .
        .
        .
    Catch...
    End Try

.... it also tends to be very fragile and hard to maintain if the class is
used in more than one place - it's a 30 year step backward in program
design.

You're handling it correctly, IMO.

-cd

Thanks very much for the advice! I wouldn't have thought of it that
way, but now that I think about it, it makes sense.

Thanks again!

and besides, what does it really matter since you have some serious job
security...

Show quoteHide quote

LOL - don't bet on that! The company's being sold!

Alvin Bruney wrote:
Show quoteHide quote

UDP socket with multiple ports
DataGridViewComboBoxes for numeric fields
specify clr version
System.Windows.Forms.ColumnHeader and IDisposable
Remoting: security and app.config