«

another interesting thought... why can i put this outside a try/catch and it
doesn't blow things up? if it raises an exception, the code doesn't seem to
care...

jeff

"Scott" <> wrote in message
news:...
> As Jason said: take a look at ThreadAbortException (and also
> response.redirect).
>
> The following are taken from the MSDN Help:
>
> HttpResponse.Redirect(string):
> Redirect calls End which raises a ThreadAbortException exception upon
> completion.
>
> ThreadAbortException:
> When a call is made to the Abort method to destroy a thread, the
> common language runtime throws a ThreadAbortException.
> ThreadAbortException is a special exception that can be caught, but it
> will automatically be raised again at the end of the catch block.
>
> I hope that helps.
> Scott
>
> "jeff" <> wrote in message
> news:...
> > happens when you issue thread.abort on a thread. this isn't
> happening.
> > it's a single thread and nowhere do i do any thread controls.
> >
> > jeff
> >
> > "Jason" <987654321> wrote in message
> > news:...
> > > no offense here but you really should read up on
> ThreadAbortException and
> > > its siblings
> > >
> > >
> > > "jeff" <> wrote in message
> > > news:...
> > > > i am using asp .net 1.1. i am having a very strange problem. i
> had a
> > > batch
> > > > of code that was working great. i made a couple of changes and
> i
> > noticed
> > > it
> > > > was always throwing an exception. i worked on it and below is
> the code
> > in
> > > > the event that causes the pseudo exception. here is the strange
> thing -
> > i
> > > > have my debugger set to break on all errors regardless of
> whether it is
> > > > handled or not. it never breaks into the debugger. the
> exception
> > > reported
> > > > is "thread is aborting" or something like that. this is bogus
> because
> > i'm
> > > > not running a multi-threaded app! so, since i was convinced
> this was a
> > > > bogus error, i moved the response.redirect outside of the
> try/catch
> > block
> > > > and it worked fine. can anybody explain this to me? also, this
> code
> > used
> > > > to work fine.
> > > >
> > > > ' try to get data
> > > > Try
> > > >
> > > > ' if made it this far, redirect to the report page.
> > > >
> > > > Response.Redirect("report.aspx")
> > > >
> > > > Catch ex As Exception
> > > >
> > > > ' set error condition to prompt user
> > > >
> > > > Session.Item(clsConstants.clsSession.MAIN_ERROR) = True
> > > >
> > > > Session.Item(clsConstants.clsSession.EXCEPTION) = ex
> > > >
> > > > DisplayError(Session.Item(clsConstants.clsSession. EXCEPTION),
> Page,
> > True)
> > > >
> > > > End Try
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

i already changed my code to catch the threadabortexception and just do
nothing with it.... thanks.

jeff

"Scott" <> wrote in message
news:...
> Jeff,
>
> This is _only_ my view of things, maybe some MS person or other more
> knowing person has a better answer, but I'll explain the way that I
> see these things.
>
> Each request is handled by "your application" (the aspnet_wp.exe
> process). When a new request comes in, the process creates a new
> thread to handle the request. For me, this is why, when the
> threadabort exception is thrown in this thread, there is nothing to
> blow up, except the thread, and it dies anyway. Response.Redirect()
> must be a bit fancy though, since, even to me, it seems to be killing
> the very thread it is running on, but no matter. Ignore this detail.
>
> About catching the error: this i do all the time. As it said in the
> ThreadAbortException help though, the exception is rethrown
> immediately after the catch block, so if you had something like the
> following:
>
> // handles pageload event
> private void Page_Load(object, args) {
> // do some stuff
> try { Response.Redirect(http://www.thegameoflife.com) }
> catch (Exception ex) {
> Console.WriteLine(ex.GetType().ToString(); }
> }
>
> the exception would be caught and
> "System.Threading.ThreadAbortException" should (I haven't tried it
> lately) be written to the output window. Note that if you do a
> Response.Write(ex.Message) it will work, but is meaningless since the
> response is redirected, and therefore cleared. In general I would
> avoid having a Response.Redirect() inside a try/catch, because you
> always know it's going to throw an exception and, as the gurus tell
> us, throwing & catching the exceptions has a bit of performance
> overhead.
>
> Let me know if that clear things up or makes them more confusing.
> scott
>
> "jeff" <> wrote in message
> news:...
> > another interesting thought... why can i put this outside a
> try/catch and it
> > doesn't blow things up? if it raises an exception, the code doesn't
> seem to
> > care...
> >
> > jeff
> >
> > "Scott" <> wrote in message
> > news:...
> > > As Jason said: take a look at ThreadAbortException (and also
> > > response.redirect).
> > >
> > > The following are taken from the MSDN Help:
> > >
> > > HttpResponse.Redirect(string):
> > > Redirect calls End which raises a ThreadAbortException exception
> upon
> > > completion.
> > >
> > > ThreadAbortException:
> > > When a call is made to the Abort method to destroy a thread, the
> > > common language runtime throws a ThreadAbortException.
> > > ThreadAbortException is a special exception that can be caught,
> but it
> > > will automatically be raised again at the end of the catch block.
> > >
> > > I hope that helps.
> > > Scott
> > >
> > > "jeff" <> wrote in message
> > > news:...
> > > > happens when you issue thread.abort on a thread. this isn't
> > > happening.
> > > > it's a single thread and nowhere do i do any thread controls.
> > > >
> > > > jeff
> > > >
> > > > "Jason" <987654321> wrote in
> message
> > > > news:...
> > > > > no offense here but you really should read up on
> > > ThreadAbortException and
> > > > > its siblings
> > > > >
> > > > >
> > > > > "jeff" <> wrote in message
> > > > > news:...
> > > > > > i am using asp .net 1.1. i am having a very strange
> problem. i
> > > had a
> > > > > batch
> > > > > > of code that was working great. i made a couple of changes
> and
> > > i
> > > > noticed
> > > > > it
> > > > > > was always throwing an exception. i worked on it and below
> is
> > > the code
> > > > in
> > > > > > the event that causes the pseudo exception. here is the
> strange
> > > thing -
> > > > i
> > > > > > have my debugger set to break on all errors regardless of
> > > whether it is
> > > > > > handled or not. it never breaks into the debugger. the
> > > exception
> > > > > reported
> > > > > > is "thread is aborting" or something like that. this is
> bogus
> > > because
> > > > i'm
> > > > > > not running a multi-threaded app! so, since i was convinced
> > > this was a
> > > > > > bogus error, i moved the response.redirect outside of the
> > > try/catch
> > > > block
> > > > > > and it worked fine. can anybody explain this to me? also,
> this
> > > code
> > > > used
> > > > > > to work fine.
> > > > > >
> > > > > > ' try to get data
> > > > > > Try
> > > > > >
> > > > > > ' if made it this far, redirect to the report page.
> > > > > >
> > > > > > Response.Redirect("report.aspx")
> > > > > >
> > > > > > Catch ex As Exception
> > > > > >
> > > > > > ' set error condition to prompt user
> > > > > >
> > > > > > Session.Item(clsConstants.clsSession.MAIN_ERROR) = True
> > > > > >
> > > > > > Session.Item(clsConstants.clsSession.EXCEPTION) = ex
> > > > > >
> > > > > >
> DisplayError(Session.Item(clsConstants.clsSession. EXCEPTION),
> > > Page,
> > > > True)
> > > > > >
> > > > > > End Try
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Scott

That makes for a slow exception handler. Probably quicker to catch it.
Besides - that is a very Vb specific command. There is no C# equivalent
other than coding that When statement in the block. Would be interesting to
see the MSIL on that one - its going to be in the exception handling block
in any case i am sure.

Cheers

Jason



"Scott" <> wrote in message
news:...
> jeff,
>
> Somewhere deep in the mysterious jungle of the MS help, they recommend
> to do nothing with an exception unless you are going to handle it. In
> the case of just try (response.redirect) catch (do nothing), it does
> not make sense to catch the exception. That said, it doesn't really
> hurt. Here's another something I stumbled on recently:
>
> Try
> 'do some stuff
> Response.Redirect("foo.aspx")
> Catch ex As Exception When Not TypeOf ex Is ThreadAbortException
> 'handle other kinds of exceptions
> End Try
>
> Hope that helps,
> scott
>
> "jeff" <> wrote in message
> news:%...
> > i already changed my code to catch the threadabortexception and just
> do
> > nothing with it.... thanks.
> >
> > jeff
> >
> > "Scott" <> wrote in message
> > news:...
> > > Jeff,
> > >
> > > This is _only_ my view of things, maybe some MS person or other
> more
> > > knowing person has a better answer, but I'll explain the way that
> I
> > > see these things.
> > >
> > > Each request is handled by "your application" (the aspnet_wp.exe
> > > process). When a new request comes in, the process creates a new
> > > thread to handle the request. For me, this is why, when the
> > > threadabort exception is thrown in this thread, there is nothing
> to
> > > blow up, except the thread, and it dies anyway.
> Response.Redirect()
> > > must be a bit fancy though, since, even to me, it seems to be
> killing
> > > the very thread it is running on, but no matter. Ignore this
> detail.
> > >
> > > About catching the error: this i do all the time. As it said in
> the
> > > ThreadAbortException help though, the exception is rethrown
> > > immediately after the catch block, so if you had something like
> the
> > > following:
> > >
> > > // handles pageload event
> > > private void Page_Load(object, args) {
> > > // do some stuff
> > > try { Response.Redirect(http://www.thegameoflife.com) }
> > > catch (Exception ex) {
> > > Console.WriteLine(ex.GetType().ToString(); }
> > > }
> > >
> > > the exception would be caught and
> > > "System.Threading.ThreadAbortException" should (I haven't tried it
> > > lately) be written to the output window. Note that if you do a
> > > Response.Write(ex.Message) it will work, but is meaningless since
> the
> > > response is redirected, and therefore cleared. In general I would
> > > avoid having a Response.Redirect() inside a try/catch, because you
> > > always know it's going to throw an exception and, as the gurus
> tell
> > > us, throwing & catching the exceptions has a bit of performance
> > > overhead.
> > >
> > > Let me know if that clear things up or makes them more confusing.
> > > scott
> > >
> > > "jeff" <> wrote in message
> > > news:...
> > > > another interesting thought... why can i put this outside a
> > > try/catch and it
> > > > doesn't blow things up? if it raises an exception, the code
> doesn't
> > > seem to
> > > > care...
> > > >
> > > > jeff
> > > >
> > > > "Scott" <> wrote in message
> > > > news:...
> > > > > As Jason said: take a look at ThreadAbortException (and also
> > > > > response.redirect).
> > > > >
> > > > > The following are taken from the MSDN Help:
> > > > >
> > > > > HttpResponse.Redirect(string):
> > > > > Redirect calls End which raises a ThreadAbortException
> exception
> > > upon
> > > > > completion.
> > > > >
> > > > > ThreadAbortException:
> > > > > When a call is made to the Abort method to destroy a thread,
> the
> > > > > common language runtime throws a ThreadAbortException.
> > > > > ThreadAbortException is a special exception that can be
> caught,
> > > but it
> > > > > will automatically be raised again at the end of the catch
> block.
> > > > >
> > > > > I hope that helps.
> > > > > Scott
> > > > >
> > > > > "jeff" <> wrote in message
> > > > > news:...
> > > > > > happens when you issue thread.abort on a thread. this isn't
> > > > > happening.
> > > > > > it's a single thread and nowhere do i do any thread
> controls.
> > > > > >
> > > > > > jeff
> > > > > >
> > > > > > "Jason" <987654321> wrote in
> > > message
> > > > > > news:...
> > > > > > > no offense here but you really should read up on
> > > > > ThreadAbortException and
> > > > > > > its siblings
> > > > > > >
> > > > > > >
> > > > > > > "jeff" <> wrote in message
> > > > > > > news:...
> > > > > > > > i am using asp .net 1.1. i am having a very strange
> > > problem. i
> > > > > had a
> > > > > > > batch
> > > > > > > > of code that was working great. i made a couple of
> changes
> > > and
> > > > > i
> > > > > > noticed
> > > > > > > it
> > > > > > > > was always throwing an exception. i worked on it and
> below
> > > is
> > > > > the code
> > > > > > in
> > > > > > > > the event that causes the pseudo exception. here is the
> > > strange
> > > > > thing -
> > > > > > i
> > > > > > > > have my debugger set to break on all errors regardless
> of
> > > > > whether it is
> > > > > > > > handled or not. it never breaks into the debugger. the
> > > > > exception
> > > > > > > reported
> > > > > > > > is "thread is aborting" or something like that. this is
> > > bogus
> > > > > because
> > > > > > i'm
> > > > > > > > not running a multi-threaded app! so, since i was
> convinced
> > > > > this was a
> > > > > > > > bogus error, i moved the response.redirect outside of
> the
> > > > > try/catch
> > > > > > block
> > > > > > > > and it worked fine. can anybody explain this to me?
> also,
> > > this
> > > > > code
> > > > > > used
> > > > > > > > to work fine.
> > > > > > > >
> > > > > > > > ' try to get data
> > > > > > > > Try
> > > > > > > >
> > > > > > > > ' if made it this far, redirect to the report page.
> > > > > > > >
> > > > > > > > Response.Redirect("report.aspx")
> > > > > > > >
> > > > > > > > Catch ex As Exception
> > > > > > > >
> > > > > > > > ' set error condition to prompt user
> > > > > > > >
> > > > > > > > Session.Item(clsConstants.clsSession.MAIN_ERROR) = True
> > > > > > > >
> > > > > > > > Session.Item(clsConstants.clsSession.EXCEPTION) = ex
> > > > > > > >
> > > > > > > >
> > > DisplayError(Session.Item(clsConstants.clsSession. EXCEPTION),
> > > > > Page,
> > > > > > True)
> > > > > > > >
> > > > > > > > End Try
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>

Jason,

Yes I agree. I wrote in VB for about 6 months, got comfortable with
the framework, then switched to c#. (I actually had to look up the
exact syntax for the When clause in old code.)

I prefer setting a flag in the catch for stuff like that now. I would
do

Dim flag as Boolean

Try
'some stuff
flag = true
Catch ex As Exception
'exception handling code
flag = false
End Try

If flag Then Response.Redirect("")

for example. I would be interested in something a bit more elegate
though.

Scott


"Jason" <987654321> wrote in message
news:...
> Scott
>
> That makes for a slow exception handler. Probably quicker to catch
it.
> Besides - that is a very Vb specific command. There is no C#
equivalent
> other than coding that When statement in the block. Would be
interesting to
> see the MSIL on that one - its going to be in the exception handling
block
> in any case i am sure.
>
> Cheers
>
> Jason
>
>
>
> "Scott" <> wrote in message
> news:...
> > jeff,
> >
> > Somewhere deep in the mysterious jungle of the MS help, they
recommend
> > to do nothing with an exception unless you are going to handle it.
In
> > the case of just try (response.redirect) catch (do nothing), it
does
> > not make sense to catch the exception. That said, it doesn't
really
> > hurt. Here's another something I stumbled on recently:
> >
> > Try
> > 'do some stuff
> > Response.Redirect("foo.aspx")
> > Catch ex As Exception When Not TypeOf ex Is ThreadAbortException
> > 'handle other kinds of exceptions
> > End Try
> >
> > Hope that helps,
> > scott
> >
> > "jeff" <> wrote in message
> > news:%...
> > > i already changed my code to catch the threadabortexception and
just
> > do
> > > nothing with it.... thanks.
> > >
> > > jeff
> > >
> > > "Scott" <> wrote in message
> > > news:...
> > > > Jeff,
> > > >
> > > > This is _only_ my view of things, maybe some MS person or
other
> > more
> > > > knowing person has a better answer, but I'll explain the way
that
> > I
> > > > see these things.
> > > >
> > > > Each request is handled by "your application" (the
aspnet_wp.exe
> > > > process). When a new request comes in, the process creates a
new
> > > > thread to handle the request. For me, this is why, when the
> > > > threadabort exception is thrown in this thread, there is
nothing
> > to
> > > > blow up, except the thread, and it dies anyway.
> > Response.Redirect()
> > > > must be a bit fancy though, since, even to me, it seems to be
> > killing
> > > > the very thread it is running on, but no matter. Ignore this
> > detail.
> > > >
> > > > About catching the error: this i do all the time. As it said
in
> > the
> > > > ThreadAbortException help though, the exception is rethrown
> > > > immediately after the catch block, so if you had something
like
> > the
> > > > following:
> > > >
> > > > // handles pageload event
> > > > private void Page_Load(object, args) {
> > > > // do some stuff
> > > > try { Response.Redirect(http://www.thegameoflife.com) }
> > > > catch (Exception ex) {
> > > > Console.WriteLine(ex.GetType().ToString(); }
> > > > }
> > > >
> > > > the exception would be caught and
> > > > "System.Threading.ThreadAbortException" should (I haven't
tried it
> > > > lately) be written to the output window. Note that if you do
a
> > > > Response.Write(ex.Message) it will work, but is meaningless
since
> > the
> > > > response is redirected, and therefore cleared. In general I
would
> > > > avoid having a Response.Redirect() inside a try/catch, because
you
> > > > always know it's going to throw an exception and, as the gurus
> > tell
> > > > us, throwing & catching the exceptions has a bit of
performance
> > > > overhead.
> > > >
> > > > Let me know if that clear things up or makes them more
confusing.
> > > > scott
> > > >
> > > > "jeff" <> wrote in message
> > > > news:...
> > > > > another interesting thought... why can i put this outside a
> > > > try/catch and it
> > > > > doesn't blow things up? if it raises an exception, the code
> > doesn't
> > > > seem to
> > > > > care...
> > > > >
> > > > > jeff
> > > > >
> > > > > "Scott" <> wrote in message
> > > > > news:...
> > > > > > As Jason said: take a look at ThreadAbortException (and
also
> > > > > > response.redirect).
> > > > > >
> > > > > > The following are taken from the MSDN Help:
> > > > > >
> > > > > > HttpResponse.Redirect(string):
> > > > > > Redirect calls End which raises a ThreadAbortException
> > exception
> > > > upon
> > > > > > completion.
> > > > > >
> > > > > > ThreadAbortException:
> > > > > > When a call is made to the Abort method to destroy a
thread,
> > the
> > > > > > common language runtime throws a ThreadAbortException.
> > > > > > ThreadAbortException is a special exception that can be
> > caught,
> > > > but it
> > > > > > will automatically be raised again at the end of the catch
> > block.
> > > > > >
> > > > > > I hope that helps.
> > > > > > Scott
> > > > > >
> > > > > > "jeff" <> wrote in message
> > > > > > news:...
> > > > > > > happens when you issue thread.abort on a thread. this
isn't
> > > > > > happening.
> > > > > > > it's a single thread and nowhere do i do any thread
> > controls.
> > > > > > >
> > > > > > > jeff
> > > > > > >
> > > > > > > "Jason" <987654321> wrote
in
> > > > message
> > > > > > > news:...
> > > > > > > > no offense here but you really should read up on
> > > > > > ThreadAbortException and
> > > > > > > > its siblings
> > > > > > > >
> > > > > > > >
> > > > > > > > "jeff" <> wrote in message
> > > > > > > > news:...
> > > > > > > > > i am using asp .net 1.1. i am having a very strange
> > > > problem. i
> > > > > > had a
> > > > > > > > batch
> > > > > > > > > of code that was working great. i made a couple of
> > changes
> > > > and
> > > > > > i
> > > > > > > noticed
> > > > > > > > it
> > > > > > > > > was always throwing an exception. i worked on it
and
> > below
> > > > is
> > > > > > the code
> > > > > > > in
> > > > > > > > > the event that causes the pseudo exception. here is
the
> > > > strange
> > > > > > thing -
> > > > > > > i
> > > > > > > > > have my debugger set to break on all errors
regardless
> > of
> > > > > > whether it is
> > > > > > > > > handled or not. it never breaks into the debugger.
the
> > > > > > exception
> > > > > > > > reported
> > > > > > > > > is "thread is aborting" or something like that.
this is
> > > > bogus
> > > > > > because
> > > > > > > i'm
> > > > > > > > > not running a multi-threaded app! so, since i was
> > convinced
> > > > > > this was a
> > > > > > > > > bogus error, i moved the response.redirect outside
of
> > the
> > > > > > try/catch
> > > > > > > block
> > > > > > > > > and it worked fine. can anybody explain this to me?
> > also,
> > > > this
> > > > > > code
> > > > > > > used
> > > > > > > > > to work fine.
> > > > > > > > >
> > > > > > > > > ' try to get data
> > > > > > > > > Try
> > > > > > > > >
> > > > > > > > > ' if made it this far, redirect to the report page.
> > > > > > > > >
> > > > > > > > > Response.Redirect("report.aspx")
> > > > > > > > >
> > > > > > > > > Catch ex As Exception
> > > > > > > > >
> > > > > > > > > ' set error condition to prompt user
> > > > > > > > >
> > > > > > > > > Session.Item(clsConstants.clsSession.MAIN_ERROR) =
True
> > > > > > > > >
> > > > > > > > > Session.Item(clsConstants.clsSession.EXCEPTION) = ex
> > > > > > > > >
> > > > > > > > >
> > > > DisplayError(Session.Item(clsConstants.clsSession. EXCEPTION),
> > > > > > Page,
> > > > > > > True)
> > > > > > > > >
> > > > > > > > > End Try
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>