Re: bizaar exception that isn't really an exception

Discussion in 'ASP .Net' started by jeff, Jun 24, 2003.

  1. jeff

    jeff Guest

    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
    > > > >
    > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
    jeff, Jun 24, 2003
    #1
    1. Advertising

  2. jeff

    jeff Guest

    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
    > > > > > >
    > > > > > >
    > > > > > >
    > > > > > >
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
    jeff, Jun 25, 2003
    #2
    1. Advertising

  3. jeff

    Jason Guest

    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, Jun 26, 2003
    #3
  4. jeff

    Scott Guest

    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
    > > > > > > > > >
    > > > > > > > > >
    > > > > > > > > >
    > > > > > > > > >
    > > > > > > > >
    > > > > > > > >
    > > > > > > >
    > > > > > > >
    > > > > > >
    > > > > > >
    > > > > >
    > > > > >
    > > > >
    > > > >
    > > >
    > > >

    > >
    > >

    >
    >
    Scott, Jun 26, 2003
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jeff
    Replies:
    0
    Views:
    1,519
  2. Amir
    Replies:
    3
    Views:
    583
  3. TN Bella
    Replies:
    0
    Views:
    470
    TN Bella
    Jul 2, 2004
  4. Nik Coughlin

    brucie isn't really dead is he?

    Nik Coughlin, Oct 2, 2006, in forum: HTML
    Replies:
    1
    Views:
    341
    Toby Inkster
    Oct 2, 2006
  5. Ralf Müller

    serializing webcontrols isn't really a good practice - is it?

    Ralf Müller, Dec 13, 2004, in forum: ASP .Net Web Controls
    Replies:
    1
    Views:
    129
    Teemu Keiski
    Dec 19, 2004
Loading...

Share This Page