CODING PRACTICE: Returning from function inside a TRY/CATCH block?

[Savvoulidis Iordanis]

Is it right when placing the RETURN statement inside the TRY or inside the
CATCH statement, when there is a FINALLY clause? Especially when there is a
transaction going on, in the try/catch block?

I give you the following example to meka it more clear:
(I use Enterprise Library, but the same also applies without it)

public function f_SomeFunction(parm1,....) as integer
dim tr as DbTransaction

Using conn As DbConnection = db.CreateConnection()
conn.Open()

tr = conn.BeginTransaction()

try
...db action 1
...db action 2
...db action 3
tr.Commit()
return 1

catch ex as Exception
tr.Rollback()
Dim rethrow As Boolean = ExceptionPolicy.HandleException(ex,
"POLICY_NAME_HERE")
If rethrow Then
Throw
End If

return -1

finally
conn.Close()
end try
end using
end function

Or instead, I should just set a flag variable rather than commiting/rolling
back (eg. b_ok to TRUE in the TRY clause or FALSE in the CATCH block) and
then check its value outside the TRY/CATCH block or the Using block and see
if I should Return 1 or -1?

I don't know if it's just a matter of programming preference or I could
sometime get unexpected behavior. Which is the common practice? Any help is
appreciated

TIA
Iordanis

 

[Peter Lykkegaard]

Is it right when placing the RETURN statement inside the TRY or inside the
CATCH statement, when there is a FINALLY clause?

When ever you have a return statement you are exiting your method
immediately and the connection is not closed

- Peter

 

[George]

That is incorrrect..

If you closing your connection inside of Finally block then even if you
exiting with Return Finally block will run and connection will close...

George.

 

[George]

Your code is perfectly fine except a little confusing.
If you using "Using" statement then i do not see need to use try/finally
block. Use one or another. You do not need both. But in your case you want
to actually catch exception so kill the Using statement.
Just move tr = conn.BeginTransaction() into try statement.
So i would rewrite it as follow (I moved tr = conn.BeginTransaction()
and also checking on tr not beign Nothing befor doing tr.Rollback since
BeginTransaction can throw an error and tr will be Nothing

public function f_SomeFunction(parm1,....) as integer
dim tr as DbTransaction
Dim conn As DbConnection = db.CreateConnection()
conn.Open()
try
tr = conn.BeginTransaction()
...db action 1
...db action 2
...db action 3
tr.Commit()
return 1
catch ex as Exception
if( Not tr Is Nothing )
tr.Rollback()
Dim rethrow As Boolean = ExceptionPolicy.HandleException(ex,
"POLICY_NAME_HERE")
If rethrow Then
Throw
End If
return -1
finally
conn.Close()
end try
end function



George.

 

[Peter Lykkegaard]

"George" skrev

That is incorrrect..

Ok thanks for the correction

- Peter

 

[Peter Lykkegaard]

"George" skrev

That is incorrrect..

Ok thanks for the correction

- Peter

 

[Mark Stevens]

If you using "Using" statement then i do not see need to use try/finally
block. Use one or another. You do not need both. But in your case you want

Correct me if I am wrong, but doesn't "using" tell the run-time system
to release any resources as soon as possible? This is a little
different from using the finally block to close the connection.

Also, in answer to the original poster, it is often considered good
style to only have one exit point from a method.

Regards
Mark
--
|\ _,,,---,,_ A picture used to be worth a
ZZZzzz /,`.-'`' -. ;-;;, thousand words - then along
|,4- ) )-,_. ,\ ( `'-' came television!
'---''(_/--' `-'\_)

Mark Stevens (mark at thepcsite fullstop co fullstop uk)

This message is provided "as is".

 

[Göran Andersson]

Correct me if I am wrong, but doesn't "using" tell the run-time system
to release any resources as soon as possible?

No, it disposes the object at the end of the using block, not sooner.

This is a little
different from using the finally block to close the connection.

No, a using block is just syntactic sugar for a try...finally, so there
is actually no difference at all.