0

I am trying to insert a new member into database, when there is a duplicate the catch block works ok. But when there is a new member both try and catch blocks return their messages. here is my code.

if (Request["cmd"] == "ins")
{
    try{
        mydb db = new mydb();
        member newm = new member()
        {
            Id = Request["uid"],
            Name = Request["uname"]
        };

        db.AddTomembers(newm);
        db.SaveChanges();
        Response.Write("ok");
        Response.End();
    }
    catch(Exception s) {
        Response.Write(s);
        Response.End();
    }
}
Liam
  • 27,717
  • 28
  • 128
  • 190
Narek Minaskan
  • 109
  • 1
  • 1
  • 6
  • What do you mean by "return their messages"? Note that your code would be *much* simpler to follow if you'd fix the indentation. – Jon Skeet May 03 '13 at 14:36
  • On what line does the exception occur? – gwin003 May 03 '13 at 14:36
  • 1
    it's not possible that both the complete try AND the catch is triggered.... – Laurent S. May 03 '13 at 14:36
  • what does the response look like when it's done? – Sam I am says Reinstate Monica May 03 '13 at 14:37
  • 5
    `Response.End` may be throwing your exception – Richard Friend May 03 '13 at 14:37
  • maybe it's `Response.End` that's throwing the exception, but if that's the case, you should be able to figure that out from the stack trace – Sam I am says Reinstate Monica May 03 '13 at 14:37
  • @Bartdude unless this chunk of code is called twice? – Liam May 03 '13 at 14:38
  • Learn to read exceptions. It's clear you're getting a different exception. – John Saunders May 03 '13 at 14:38
  • @Bartdude: Why not? Suppose the compiler generates a nop after the Response.End and a thread abort exception happens from another thread on that nop. In that case all the code would run in the try block and the catch block would also run. It's *possible*, it's just extremely unlikely. – Eric Lippert May 03 '13 at 14:43
  • @Eric Lippert: wow you're flying way too high for me :-) If you say it's possible because of that, my bad then, it's possible :-) – Laurent S. May 03 '13 at 14:47
  • @Bartdude: Remember what Sherlock Holmes said about eliminating the impossible! :-) It turns out that all kinds of ridiculously improbable things are actually possible. For instance: is it possible that `xor eax, eax` instruction -- not IL, the actual machine instruction for putting zero in eax -- generates a fault? Not a thread abort exception, an actual you-dereferenced-null kind of fault. Microsoft gets lots of crash reports and a vanishingly small but non-zero percentage of them indicate that this triggered the fault. How is that possible? See if you can figure it out. – Eric Lippert May 03 '13 at 15:44
  • The solution is here: http://blogs.msdn.com/b/oldnewthing/archive/2005/04/12/407562.aspx – Eric Lippert May 03 '13 at 15:46

3 Answers3

6

It's not really clear from the question, but I strongly suspect that the problem is that Response.End() throws an exception (ThreadAbortException) as documented:

To mimic the behavior of the End method in ASP, this method tries to raise a [ThreadAbortException] exception. If this attempt is successful, the calling thread will be aborted, which is detrimental to your site's performance. In that case, no code after the call to the End method is executed.

You're capturing that exception and then calling it again. Just move the Response.End to a finally block - or ideally, get rid of it entirely, structuring your control flow so you don't need it... again, as documented:

This method is provided only for compatibility with ASP—that is, for compatibility with COM-based Web-programming technology that preceded ASP.NET. If you want to jump ahead to the EndRequest event and send a response to the client, it is usually preferable to call CompleteRequest instead.

(Note that if you'd caught a specific exception rather than just Exception, you wouldn't have this problem either.)

Daniel A.A. Pelsmaeker
  • 47,471
  • 20
  • 111
  • 157
Jon Skeet
  • 1,421,763
  • 867
  • 9,128
  • 9,194
  • 1
    @Andomar: No, you can catch it - but it will be automatically rethrown at the end of the `catch` block unless you explicitly suppress that behaviour. – Jon Skeet May 03 '13 at 14:39
  • well the exception occur when i am trying to insert a duplicate into database and it works properly. but if i remove Response.End() , i will be sending the rest of the html to client. i just want to send a simple message to say it was successful or not . – Narek Minaskan May 03 '13 at 15:03
  • @NarekMinaskan: What "rest of the HTML"? You haven't given us enough context here. Why would you need to send extra HTML at all? It sounds like you should probably reconsider your design for this. – Jon Skeet May 03 '13 at 15:35
  • No i mean , if i dont use the response.end() , its going to send the html of my page , it is visible when i alert the data from server – Narek Minaskan May 03 '13 at 16:25
  • @NarekMinaskan: My point is that it would be better if you could take a more MVC-like approach where the response you generate is governed by the earlier results. Anyway, just moving `Response.End()` to *after* the catch block (and only having one call to it) should be a hacky way round for the moment. – Jon Skeet May 03 '13 at 16:30
1

If both ok and the exception message s are written, it's the Response.End() that is throwing the exception. Examine s to find out what is going on.

A guess: Is Response.End() considered harmful?

Community
  • 1
  • 1
Emond
  • 50,210
  • 11
  • 84
  • 115
0

If you are trying to call the Response.End() on the Page_Load event of the asp.net, it will not work properly. Take a look at this thread: Response.End () doesn't abort current thread, and see how to solve it.

Try to avoid Responses on asp.net application, try to show panels, use labels to show messages.

Community
  • 1
  • 1
Felipe Oriani
  • 37,948
  • 19
  • 131
  • 194