http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660I think consistency is the most important. As long as users know exactly where to look up the error every times they'll generally be happy. http://ayende.com/3881/production-errors-best-practices#comment7http://ayende.com/3881/production-errors-best-practices#comment7Fri, 20 Feb 2009 00:10:14 GMTI would google for "Could not find order attribute with the name" - a piece of error message, not for useless and almost meaningless ID. Googling for pieces of error message text gives you some flexibility in finding similar problems. Also I think that error ID expressed in numbers like 0x99334422 are better because you don't have to think about naming the ID (which is just another area for programmer jokes). http://ayende.com/3881/production-errors-best-practices#comment6http://ayende.com/3881/production-errors-best-practices#comment6Thu, 19 Feb 2009 20:26:09 GMTRafal, You ignore one very important issue. Being able to lookup the error easily, and being able to trip it easily http://ayende.com/3881/production-errors-best-practices#comment5http://ayende.com/3881/production-errors-best-practices#comment5Wed, 18 Feb 2009 13:37:38 GMTSimon, I agree with you. Occasional 'developer jokes' could be fun, but not anymore if every message wants to be funny. Also, let's think who is the intended reader of these messages. If it's a developer or technically-aware admin, he will probably know that deployment went wrong and ordinary 'missing column XXX in table YYY' message would be sufficient. For other exceptions, it's a good practice to add some context information, for example name of the file or database table where the error occurred. Error codes, like ERROR_ORDER_ATTRIB_NOT_FOUND - don't work in my opinion and it doesn't make sense to give some code to every possible application error, especially when there is no other information available. Look at almost totally useless HRESULTS. http://ayende.com/3881/production-errors-best-practices#comment4http://ayende.com/3881/production-errors-best-practices#comment4Wed, 18 Feb 2009 10:57:12 GMTDid you really put that last sentence in the deployed application? I wouldn't. I'm so tired of working with code containing stuff that the author thought was funny. It's NEVER funny, especially when you get an exception. This also applies to comments. Today, I came across a comment (in the linux kernel, mind you) which says "I see dead people", a reference to the movie "The sixth sense". Now, believe me, that part of code actually *needed* a comment, and all I got was that lousy reference. I guess it made some sense to the author. Not to me. (ok, the code was actually de-allocating some "dead" structures... but still). I believe I have a very good sense of humor, but I just don't find those types of "jokes" funny. Not anymore, anyway. To be fair, the rest of the post is incredibly useful in listing how to make sure an exception actually communicates information instead of just barfing uselessness ;) http://ayende.com/3881/production-errors-best-practices#comment3http://ayende.com/3881/production-errors-best-practices#comment3Wed, 18 Feb 2009 01:47:19 GMTI suggest you make the "not been properly prepared for the deployment" and "are also missing" bold and somehow highlighted because users may not read this rather long message... Of course, that depends on what exactly causes the message. http://ayende.com/3881/production-errors-best-practices#comment2http://ayende.com/3881/production-errors-best-practices#comment2Wed, 18 Feb 2009 01:39:40 GMTIts certainly much better than many of the standard KeyNotFound, DuplicateKey and NullReference style exceptions! http://ayende.com/3881/production-errors-best-practices#comment1http://ayende.com/3881/production-errors-best-practices#comment1Wed, 18 Feb 2009 01:36:57 GMT