try\catch getting the right line number

[Jeff Jarrell]

I have a block of code that during development is prone to casting errors.
It is mostly a DataReader type thing.

It looks something like this.

_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")

myDLReader.close

If I don't put it in a try catch block, I can get the right line number as
it bubbles out to try\catch outward. But because I need to put his same
thing into a Transaction, I get an error if I don't get to the
MyDlReader.Close() before the rollback AND the rollback comes before the
Handling of the exception (logging, gui msg, etc). So the original error
gets swallowed up.

So easy enough, put it all into a Try\Catch block and Ensure the reader gets
closed. But as the original exception is rethrown (Throw or Throw ex) the
line number changes to the subsequent Throw line and the "real" line number
is lost.

Try
_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")
catch (ex as exception)
MyDlReader.Close() <--- at this point the ex.StackTrace has the
line number i want
Throw ex <--- the catcher of this gets StackTrace
as being line (aargh)
end try

Ideas?

Thanks,
jeff

[rowe_newsgroups]

On Apr 5, 8:20 pm, "Jeff Jarrell" <[e-mail]:

I have a block of code that during development is prone to casting errors.
It is mostly a DataReader type thing.

It looks something like this.

_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")

myDLReader.close

If I don't put it in a try catch block, I can get the right line number as
it bubbles out to try\catch outward. But because I need to put his same
thing into a Transaction, I get an error if I don't get to the
MyDlReader.Close() before the rollback AND the rollback comes before the
Handling of the exception (logging, gui msg, etc). So the original error
gets swallowed up.

So easy enough, put it all into a Try\Catch block and Ensure the reader gets
closed. But as the original exception is rethrown (Throw or Throw ex) the
line number changes to the subsequent Throw line and the "real" line number
is lost.

Try
_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")
catch (ex as exception)
MyDlReader.Close() <--- at this point the ex.StackTrace has the
line number i want
Throw ex <--- the catcher of this gets StackTrace
as being line (aargh)
end try

Ideas?

Thanks,
jeff

Why do you need to know the line number in the first place? In the
release version line numbers will not exist, so you can't use it for
error logging.

Also, if you want to make sure the datareader gets closed you should
put MyDlReader.Close() in a finally block of the try...end try
statement.

Thanks,

Seth Rowe

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Jeff Jarrell wrote:

I have a block of code that during development is prone to casting errors.
It is mostly a DataReader type thing.

It looks something like this.

_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")

myDLReader.close

If I don't put it in a try catch block, I can get the right line number as
it bubbles out to try\catch outward. But because I need to put his same
thing into a Transaction, I get an error if I don't get to the
MyDlReader.Close() before the rollback AND the rollback comes before the
Handling of the exception (logging, gui msg, etc). So the original error
gets swallowed up.

So easy enough, put it all into a Try\Catch block and Ensure the reader gets
closed. But as the original exception is rethrown (Throw or Throw ex) the
line number changes to the subsequent Throw line and the "real" line number
is lost.

Try
_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")
catch (ex as exception)
MyDlReader.Close() <--- at this point the ex.StackTrace has the
line number i want
Throw ex <--- the catcher of this gets StackTrace

Just use:

Throw

as being line (aargh)
end try

Ideas?

Thanks,
jeff

--
Göran Andersson
_____
http://www.guffa.com

[Jeff Jarrell]

The line numbers are ONLY needed during development.

Currently I am involved in a large port\migration effort. Aside from a
signficant Vb6\Php migration to .Net we are also moving from where we only
supported MySQL into an database neutral environment where we will be
supporting multiple databases (mysql, mssql, and possibly oracle. Needless
to say the the underlying data types are different. The way we are managing
this is to map out the data type differences within StoredProcedures. Each
DB has its own set of stored procedures. Now on the .Net side we have these
Codesmith generated wrappers. One wrapper for all of the DB Types. The
frameworks maps it out to the proper database and underlying typed data
objects (connections, parms, etc).

Since we have one wrapper per logical SP, i expect this to be a frequent
source of error in development primarily because the SPs themselves are for
the most part hand coded.

Thanks,
jeff

"rowe_newsgroups" <ro********@yahoo.comwrote in message
news:11**********************@o5g2000hsb.googlegro ups.com...

On Apr 5, 8:20 pm, "Jeff Jarrell" <[e-mail]:

>I have a block of code that during development is prone to casting
errors.
It is mostly a DataReader type thing.

It looks something like this.

_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")

myDLReader.close

If I don't put it in a try catch block, I can get the right line number
as
it bubbles out to try\catch outward. But because I need to put his same
thing into a Transaction, I get an error if I don't get to the
MyDlReader.Close() before the rollback AND the rollback comes before the
Handling of the exception (logging, gui msg, etc). So the original error
gets swallowed up.

So easy enough, put it all into a Try\Catch block and Ensure the reader
gets
closed. But as the original exception is rethrown (Throw or Throw ex)
the
line number changes to the subsequent Throw line and the "real" line
number
is lost.

Try
_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")
catch (ex as exception)
MyDlReader.Close() <--- at this point the ex.StackTrace has the
line number i want
Throw ex <--- the catcher of this gets
StackTrace
as being line (aargh)
end try

Ideas?

Thanks,
jeff

Why do you need to know the line number in the first place? In the
release version line numbers will not exist, so you can't use it for
error logging.

Also, if you want to make sure the datareader gets closed you should
put MyDlReader.Close() in a finally block of the try...end try
statement.

Thanks,

Seth Rowe

[Jeff Jarrell]

Goran,

Believe it or not I had tried it both ways. It didn't work.

I guess my out is to just grab the stack trace at that point and parse it. I
know I want it if the particular line contains "LoadRow"). I started to go
down working through the stack frames (unsuccessfully so far) before the
throw, but you know a simple regex on text will take care of it.

Thanks,
jeff

===== this is the stack trace before I throw ============
ex.StackTrace " at System.Data.SqlClient.SqlBuffer.get_Int16()
at System.Data.SqlClient.SqlDataReader.GetInt16(Int32 i)
at whi.pw.core.dal.DLReader.GetShortInteger(String fldName) in
N:\core\core\datalayer\DLReader.cs:line 189
at whi.pw.core.vb.tests.yyyUpdateDemo.RowValues.LoadR ow(DLReader
myDLReader) in N:\core\core.vb.tests\sp_wrappers\yyyUpdateDemo.vb :line 354"
String

======== The part that I am looking for is the "line 354" thing above
==============

==== Here is the stack trace in the caller, after I THROW per your
suggestion =====

StackTrace " at System.Data.SqlClient.SqlBuffer.get_Int16()\r\n
at System.Data.SqlClient.SqlDataReader.GetInt16(Int32 i)\r\n
at whi.pw.core.dal.DLReader.GetShortInteger(String fldName)
in N:\\core\\core\\datalayer\\DLReader.cs:line 189\r\n
at whi.pw.core.vb.tests.yyyUpdateDemo.RowValues.LoadR ow(DLReader
myDLReader)
in N:\\core\\core.vb.tests\\sp_wrappers\\yyyUpdateDem o.vb:line
549\r\n
at whi.pw.core.vb.tests.yyyUpdateDemo.Read()
in N:\\core\\core.vb.tests\\sp_wrappers\\yyyUpdateDem o.vb:line 62\r\n
at whi.pw.core.vb.tests.yyyUpdateDemoTask.Execute(Tas kToken myTaskToken)
in N:\\core\\core.vb.tests\\PipelineTasks\\yyyUpdateD emoTask.vb:line
20\r\n
at whi.pw.core.dal.PipelineBase.Execute(TaskToken myTaskToken) in
N:\\core\\core\\datalayer\\pipeline\\PipelineBase. cs:line 38" string

=== The "line 549" is the THROW line ====== Aargh ====

"Göran Andersson" <gu***@guffa.comwrote in message
news:eJ****************@TK2MSFTNGP02.phx.gbl...

Jeff Jarrell wrote:

>I have a block of code that during development is prone to casting
errors. It is mostly a DataReader type thing.

It looks something like this.

_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")

myDLReader.close

If I don't put it in a try catch block, I can get the right line number
as it bubbles out to try\catch outward. But because I need to put his
same thing into a Transaction, I get an error if I don't get to the
MyDlReader.Close() before the rollback AND the rollback comes before the
Handling of the exception (logging, gui msg, etc). So the original error
gets swallowed up.

So easy enough, put it all into a Try\Catch block and Ensure the reader
gets closed. But as the original exception is rethrown (Throw or Throw
ex) the line number changes to the subsequent Throw line and the "real"
line number is lost.

Try
_prtPNID = myDLReader.GetString("prtPNID")
_prtSKU = myDLReader.GetString("prtSKU")
_prtPic = myDLReader.GetString("prtPic")
_prtRsvQty = myDLReader.GetInteger("prtRsvQty")
catch (ex as exception)
MyDlReader.Close() <--- at this point the ex.StackTrace has the
line number i want
Throw ex <--- the catcher of this gets
StackTrace

Just use:

Throw

>as being line (aargh)
end try

Ideas?

Thanks,
jeff

--
Göran Andersson
_____
http://www.guffa.com