• (cs) in reply to Dustin
    Dustin:
    It just doesn't seem like there's any reason to throw an exception, or even catch that particular exception here. The programmer obviously knew that an error would occur so why not handle it at the database level with a transaction? I haven't been programming for a long time so correct me if I'm wrong, but it just seems like exceptions should be used for unforseen errors and that the errors you know are going to happen should be handled accordingly.


    The guy is not just expecting exception - he expects it to happen in regard to very particular table index. It is not an exception then, it is part of normal program flow and should be handled accordingly.
    Moreover he's using code that not only executed in different layer but could potentially run on different physical box - just to check if one of db schema constraints is violated.

    Of course you're right. I'm really surprised to see how many people are trying to correct this complete fuckup by pointing to the "proper" exception type - or even defend it.

  • (cs)

    A while back, I mentioned a little thing called CONTEXT.  We have no idea what the rest of the code is like.  We don't know what the exception is.  Maybe someone just did

       throw new Exception("Cannot insert duplicate key row in object 'ProjectIDCode' with unique "
        + "index 'adx_Projects_ProjectIDCode'.\r\n"
        + "Unexpected error inserting Profile.\r\n"
        + "The statement has been terminated.")

    THAT would be the real WTF.

    As for this only catching one exception...  Perhaps it should have more exception handlers, but then again, it all depends how this code is used.

  • (cs) in reply to johnl

    Actually, looking closer at the message, that's unlikely to be exactly what happened, but it might not be that far off.

  • (cs) in reply to WaterBreath

    WaterBreath wrote: Then, IMHO, it doesn't qualify as a simple write. ;)

    Ah, but you might not know if it's simple or not.

    In many applications, especially where there's not a good ORM in place, complex writes are hidden behind stored procedures. This enables the database to change structure without perturbing the code.

    I would, in fact, claim that if you're not using an ORM (which would hopefully return sensible errors rather than a generic SQLException) then you should be accessing everything through stored procedures, but that's a whole 'nother issue.

    Simon

  • (cs) in reply to Tarq
    Anonymous:

    On error resume stupid.

    Three thumbs up for that one.

  • (cs) in reply to Henry Troup
    Anonymous:

    IMO, error handling is not often enough addresses in architectural discussions.  How many times does only an HRESULT come back, and the level that should handle the error is left guessing about what the error was?


    Amen to this.  At my last company, we spent millions to rearchitect our platform to incorporate web services but provided no elegant way to convey an error on the web services side to the caller.  The only thing we had was an <errors> element, which contained a stacktrace.  Sure, we could parse the stacktrace but that would be answering a WTF with another.
  • (cs) in reply to Mung Kee

    The complete range of messages as returned by the DB is probably too diverse to put in a standardised SQLerror, from which information like column names can be read, so getting the string message and mangling that for the specifics is a valid practise.

    But not by hard-coding THIS ONE SINGLE SPECIFIC MESSAGE. If you know it's likely to occur, you can probably prevent it, is what I'm saying.

  • felix (unregistered) in reply to Mung Kee
    Mung Kee:
    Anonymous:

    IMO, error handling is not often enough addresses in architectural discussions.  How many times does only an HRESULT come back, and the level that should handle the error is left guessing about what the error was?


    Amen to this.  At my last company, we spent millions to rearchitect our platform to incorporate web services but provided no elegant way to convey an error on the web services side to the caller.  The only thing we had was an <errors> element, which contained a stacktrace.  Sure, we could parse the stacktrace but that would be answering a WTF with another.


    You had errors on you side of the code? Now that what I call a WTF.


    </errors>
  • (cs) in reply to felix
    Anonymous:
    Mung Kee:
    Anonymous:

    IMO, error handling is not often enough addresses in architectural discussions.  How many times does only an HRESULT come back, and the level that should handle the error is left guessing about what the error was?


    Amen to this.  At my last company, we spent millions to rearchitect our platform to incorporate web services but provided no elegant way to convey an error on the web services side to the caller.  The only thing we had was an <errors> element, which contained a stacktrace.  Sure, we could parse the stacktrace but that would be answering a WTF with another.


    You had errors on you side of the code? Now that what I call a WTF.


    </errors>


    Your English is what I call a WTF. 
  • Anon (unregistered)

    At least they're rethrowing with the "throw;" statement.

  • (cs) in reply to Tarq
    Tarq:

    WTF

    On error resume stupid.

    That actually made me laugh out loud and pull a groin muscle. Kudos, sir.

    Fuck you:

    ...a lot of weird shit

    I so badly wanted to quote all that and say "WTF?", but I'll just say... FUCK YOU GAYLORD. You can't come back from that. You can just sit there and say "Yeah, fuck me, that's right."

  • (cs) in reply to tufty
    tufty:
    WaterBreath wrote: Then, IMHO, it doesn't qualify as a simple write. ;) Ah, but you might not know if it's simple or not. In many applications, especially where there's not a good ORM in place, complex writes are hidden behind stored procedures. This enables the database to change structure without perturbing the code. I would, in fact, claim that if you're not using an ORM (which would hopefully return sensible errors rather than a generic SQLException) then you _should_ be accessing everything through stored procedures, but that's a whole 'nother issue. Simon


    If you can't be certain that the write will be simple, then it's obviously not safe to handle it as if it were.  I probably shouldn't have even mentioned the option, because if the app and database schema are both well-designed, with flexibility and scalability in mind, then that sort of tight-coupling should pretty much never be necessary or acceptable.  However in certain scenarios, where the software is never intended to be extended, or used on a large scale or long term, I don't necessarily begrudge someone cutting those corners.  And that's more what I was thinking of when I mentioned it in the first place.
  • (cs) in reply to Malyon
    Anonymous:
    Samples of other error reporting likely to be found in this program:
    ...

    if (param3 < param2 - 7) {
        lblError.Text = "Yo, that ain't how you call this function, homie.";
        return;
    }



    Thank you for that. You made me laugh very hard for at least a minute.
  • (cs) in reply to dmitriy

    Ahh nice, I'm currently doing a team based Major Project for my IT course.
    One of the team members is always handling exceptions this way, and doesn't understand my point when I try to tell him otherwise.
    Will be passing a link to this along :)

  • Experienced Coder (unregistered)

    OMFG, how stupid people can be!!!!

  • bman (unregistered) in reply to FranksAndBeans

    It wouldn't even matter.

    String comparison in java will -NEVER- work with the == operator unless it's the same -instance- of the object. Strings are immutable.

    String a = "a";
    if (a == a) // would work.

    String b = "a";
    if (a == b) // NEVER TRUE, a and b are differnet instances.

    if (a.equals(b)) // works.

    if (a != b) // ALWAYS true.


  • (cs) in reply to bman
    Anonymous:

    String a = "a";
    String b = "a";
    if (a == b) // NEVER TRUE, a and b are differnet instances.
    if (a != b) // ALWAYS true.


    Well, ahem, actually, not quite.

    Strings are immutable.  So the Java engine can elect to store strings with the same values at the same address in memory... in which case a == b might very well be true.

Leave a comment on “Exceptional Error Handling ”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article