http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660This is the result of your years of support. I don't think you should put training or enforce good practice through error messages. But, neither can I say I wouldn't do it. At the end of the day, losing some number of phone calls to your tech support is money in your pocket--both from less support AND from the bad press: "This stupid Raven thing runs so slow . . ." yada, yada, yada. I'd search hard for a more appropriate vehicle for the message. But, maybe there isn't one that would be as effective. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment31http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment31Thu, 27 May 2010 01:04:48 GMTWhat about "throw new BadCodingPracticeException" instead? http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment30http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment30Wed, 26 May 2010 18:03:28 GMTAh, so it's total requests, not current requests. I.C. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment29http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment29Tue, 25 May 2010 23:50:10 GMTSteve, The problem isn't temporary, if you make another request, it should be blocked as well. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment28http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment28Tue, 25 May 2010 23:22:46 GMT+1 to Geert ! Incrementing then throwing the exception is a bad idea. If the exception is caught and handled (I.e. make the requester wait, etc.) then you've increased the count without using a request; Poluting your request count with false requests, hindering performance when "real" requests are let go. Your intent might be that during development developers would receive this exception and re-factor their design. Real-world though is that stuff like this will come up in UAT/Production and bug fixes will effectively be jury-rigs. A caught and handled exception in this case is now a behaviour bug. It's fine to provide details within the exception, if something needs to be told to a user they should be presenting an application-meaningful exception message anyways. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment27http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment27Tue, 25 May 2010 22:33:57 GMTConceptually great, but the writing could use some help. "It is advisable that you'll look into reducing" should just be "Consider reducing". http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment26http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment26Tue, 25 May 2010 20:35:43 GMTthrow new YerDoinItWrongException(); ;-) http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment25http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment25Tue, 25 May 2010 17:25:00 GMTI like the idea. One of the things I *LOVE* about NHibernate, for example, is that the error messages usually give you enough information to know what's wrong and how to fix it without having to open a debugger every time. The only change I'd do would be introducing a MaximumNumberOfRequestsException like Dennis suggested (whether or not to derive it from InvalidOperationException is up to you) http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment24http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment24Tue, 25 May 2010 16:37:38 GMTThis is a good thing http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment23http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment23Tue, 25 May 2010 16:36:58 GMT@Dennis, you can override the default if you want to. but see [groups.google.com/.../d0cfb634b89a75e8](http://groups.google.com/group/ravendb/browse_thread/thread/b30b2faeac1e4164/d0cfb634b89a75e8?lnk=gst&q=max+queries#d0cfb634b89a75e8) for a discussion of why you might not want to. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment22http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment22Tue, 25 May 2010 16:33:33 GMTAnd then that throws an OutOfMemoryException XD http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment21http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment21Tue, 25 May 2010 15:38:15 GMTI think long error messages like this would break the rendering of UI error/warnings on the client. I prefer an error code and a 'succinct error message' and a url for a more detailed explanation where I could explore other comments and solutions from people who have also encountered this error. If you don't provide a url yourself then you should at least supply an error code so its googable. IMHO motivations behind why you've chosen to throw an error have no place in an Exception message (that's what documentation is for) - it's long enough as it is. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment20http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment20Tue, 25 May 2010 14:42:32 GMTWhat does it want me to do? http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment19http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment19Tue, 25 May 2010 13:53:17 GMTYou probably don't want to increment numberOfRequests when you throw the exception. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment18http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment18Tue, 25 May 2010 12:27:59 GMTJust great. I wish it was always like this. Both the message and the "warning" exception that you have to explicitly disable. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment17http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment17Tue, 25 May 2010 12:05:35 GMTI like these kind of error messages, because they help a developer much more than general messages (NullReferenceException anyone?). @Neil: if you use ReSharper to rename methods, it will search in strings also, so that shouldn't be a problem. Oh, also some nitpicking: ... Raven provideS facilities ... Nice work, can't wait to try out Raven. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment16http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment16Tue, 25 May 2010 11:59:53 GMTRafal, No one read the logs. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment15http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment15Tue, 25 May 2010 11:53:53 GMTNeil, Those type of things don't change often. And you basically need to remember those. Nothing really fancy or high tech. The advantage that you can get from that is huge http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment14http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment14Tue, 25 May 2010 11:53:49 GMTNice error message, but in this case I'd rather warn the administrator and continue servicing requests without scarying application users and suggesting the application is broken. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment13http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment13Tue, 25 May 2010 11:41:53 GMTAyende, Yeah, I have to admit I've always wanted to do it, but always changed my mind at the last minute because of reason I mentioned. It's kind've like documentation - it's hard to keep it up to date and in-sync with the code. Do you have any tips for keeping these kind of messages relevant over time, when there are many of them? Surely even you can't just remember where they all are and update them when something changes? :) http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment12http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment12Tue, 25 May 2010 11:36:07 GMTNeil, I learned that style from Castle, where it has been successful for over half a decade. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment11http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment11Tue, 25 May 2010 11:23:27 GMTarmoured.frog, Yes, thanks, fixed. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment10http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment10Tue, 25 May 2010 11:22:01 GMTHei guys! That is the ESSENTIAL! The idea. No more. Try to do the same proper way (resources, exception helpers, ...). And when you finish just compare your (COOL and PROPER) code with the one provided. Is it EASY to understand what you did want to explain? http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment9http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment9Tue, 25 May 2010 11:13:50 GMTI like the idea of error messages that actually say what the problem is, and even tell you what to do, but I'm torn. I'm torn because the message is effectively a kind of magic string that has details like configuration item names etc, which is going to go out of date if you refactor in the future (say for example you decide to write a clever algorithm that automatically works out the max requests value based on historical usage to determine extraordinary behaviour). http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment8http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment8Tue, 25 May 2010 10:45:16 GMTIt should throw a MaximumNumberOfRequestsException instead. You aren't doing an Invalid operation, you have just passed the useful limit. And why is it I would always have to know ahead of time how many queries I am going to be executing. This will be an absolute nightmare for an application 10 years down the road where the source code is long gone. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment7http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment7Tue, 25 May 2010 10:36:55 GMTI quite like the concept of a more responsible application. http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment6http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment6Tue, 25 May 2010 10:14:06 GMTdon't mean to nitpick..but did you mean "result in a more *responsive* application." http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment5http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment5Tue, 25 May 2010 09:56:36 GMTShouldn't it be numberOfRequests++ (a max of 1 query should mean 1 query is OK, but 2 is not) :P http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment4http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment4Tue, 25 May 2010 09:41:22 GMTThis guy seriously needs to learn about StringResources http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment3http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment3Tue, 25 May 2010 09:24:00 GMTDRY violation? http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment2http://ayende.com/4520/and-now-this-is-what-i-call-error-handling#comment2Tue, 25 May 2010 09:21:48 GMT