MVP's: Determine Dimensioning Class or Assembly

  • Thread starter Thread starter keith
  • Start date Start date
K

keith

If I declare a variable and set it = nothing then pass it byref into a
routine that accepts an optional argument of the same type with a
default of nothing, is there anyway to determine where the varable was
decalred? I know I could include another argument that specifies
whether i'm passing it in or not, but was looking for a more elegant
solution. If the dimensioning class cannot be determined, can the
dimensioning assembly?

i.e.

Dim sqlTran as SqlTransaction = Nothing
Dim objClass As New MyClass

objClass.SomeRoutine(sqlTran)



'*** Different Class ***
Class MyClass
Public Sub SomeRoutine(Optional ByRef sqlTran as SqlTransaction =
Nothing)

'was sqlTran passed in or is it the optional default?

End Sub
End Class

Thanks for your help,

-Keith
 
If I declare a variable and set it = nothing then pass it byref into a
routine that accepts an optional argument of the same type with a
default of nothing, is there anyway to determine where the varable was
decalred? I know I could include another argument that specifies
whether i'm passing it in or not, but was looking for a more elegant
solution. If the dimensioning class cannot be determined, can the
dimensioning assembly?
Click to expand...

I'd be very surprised if there were any way of determining it, but even
if such a way existed, I'd recommend against using it. Such an unusual
way of determining behaviour goes against the principle of least
surprise. If you want behaviour to differ in different situations,
create a parameter for that case.

You could always create three overloads - one with the transaction
parameter and the flag, one with neither (calling the first with
Nothing and False) and one with the transaction (calling the first with
Nothing and True).
 
I'd be very surprised if there were any way of determining it, but even
if such a way existed, I'd recommend against using it. Such an unusual
way of determining behaviour goes against the principle of least
surprise. If you want behaviour to differ in different situations,
create a parameter for that case.

You could always create three overloads - one with the transaction
parameter and the flag, one with neither (calling the first with
Nothing and False) and one with the transaction (calling the first with
Nothing and True).
Click to expand...

Thanks Jon,

I guess I have to agree with you. I was trying to avoid overloads as,
IMHO, they add clutter, but I have to agree that it is the right way
of doing things. I'm trying to create business layer routines in such
a way that they can be called with or without a transaction and can be
nest with other routines in the same transaction and only the creator
of the transaction will commit or rollback. There's an example below,
but it would be just as easy to do with two versions of each routine,
one that accepts the transaction and one that accepts nothing, creates
the transaction and calls the other. The latter of course would
handle the commit/rollback. This way would also support handling the
nesting from the UI layer allowing the UI layer to determine the fate
of the transaction.

Public Sub WCMstUpdate(Optional ByVal blnRecalc As Boolean =
False, _
Optional ByRef sqlTran As
SqlTransaction = Nothing)
Dim conn As New SqlConnection(m_strConnection)
Dim blnCommit As Boolean = sqlTran Is Nothing

Try
If sqlTran Is Nothing Then
conn.Open()
sqlTran = conn.BeginTransaction
End If

SqlHelper.ExecuteNonQuery(sqlTran, _
CommandType.StoredProcedure, _
SP_WC_MST_UPDATE)

If blnRecalc Then
Dim objOnlineDrop As New WIP.clsOnlineDrop
Call
objOnlineDrop.RecalculateWORScheduleDateByWC(sqlTran)
Call objOnlineDrop.WORoutingUpdateWCGroupFl(sqlTran)
End If

If blnCommit Then sqlTran.Commit()
Catch ex As Exception
If Not sqlTran Is Nothing And blnCommit Then
sqlTran.Rollback()
Throw
Finally
If Not conn Is Nothing Then conn.Close()
End Try
End Sub


Thanks again.
 
Back
Top