tag:blogger.com,1999:blog-22587889.post1133117277284150293..comments2024-02-11T13:21:47.930+05:30Comments on Ruminations of a Programmer: Domain Driven Design - What's in an Exception Name ?Anonymoushttp://www.blogger.com/profile/01613713587074301135noreply@blogger.comBlogger16125tag:blogger.com,1999:blog-22587889.post-44621502850171954422007-07-06T17:59:00.000+05:302007-07-06T17:59:00.000+05:30@Jing:"Folks who feel checked exceptions are neces...<I>@Jing:<BR/>"Folks who feel checked exceptions are necessary are actually falling victims of the second flaw - there aren't any compile-time support for enforcing contracts including unchecked exceptions, therefore the overly prescriptive alternative must be used."</I><BR/><BR/>I agree to this observation. I have worked in large C++ projects where it was a real pain going through half-baked documentations to find out everything about exceptions. It is an irony that people only lament on the pains of checked exceptions, but totally ignore the pain that is caused by the lack of them. I have been through the second class of sufferings and I know what it takes.<BR/><BR/>Cheers.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-84698869172835053872007-07-05T22:27:00.000+05:302007-07-05T22:27:00.000+05:30@Debasish,I absolutely agree with you that excepti...@Debasish,<BR/><BR/>I absolutely agree with you that exceptions are part of the contract. However, IMHO, an API contract should _not_ dictate implementation - either way for that matter. That an exception is part of the contract only goes as far as saying "be _prepared_ to handle this exception," but not "you _must_ handle this exception right here right now."<BR/><BR/>Again let's use the return value analogy - it's perfectly fine for a contract to say "I might return null so don't be surprised when you see one," but it's rather excessive to say "you must have an if testing my return value and do something differently if it's null."<BR/><BR/>There are, again IMHO, actually two flaws in Java's exception design. The first one is the checked exceptions themselves, and the second one the complete compile-time ignoring of unchecked ones. Folks who feel checked exceptions are necessary are actually falling victims of the second flaw - there aren't any compile-time support for enforcing contracts including unchecked exceptions, therefore the overly prescriptive alternative must be used.<BR/><BR/>What Java could have done is to make all exceptions equal, and not to force any exception handling, but instead honor the "throws" declarations, and issue warnings on those aren't handled.<BR/><BR/>I also realize that you feel stronger urge to enforce exception handling in contracts than I do, because of another philosophical difference - I think things like "insufficient balance" aren't really exceptions, and should be expressed as the status of an account or a transaction in a first-class domain object.<BR/><BR/>But I guess that's an even finer line to draw, so, another debate for another day... :-)<BR/><BR/>Cheers.<BR/>-- <BR/>JingAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-24308367878392299932007-07-04T21:42:00.000+05:302007-07-04T21:42:00.000+05:30@Jing:I fully appreciate your point of view and th...<I>@Jing:</I><BR/>I fully appreciate your point of view and the fact that many languages have learnt from Java's apparent mistake in checked exception design. This is the reason I mentioned in my earlier comment, that I am still looking for the proper camp. People who feel checked exceptions are evil say that it is not according to the doctrine of software engineering to force callers to handle exceptions. But, tell me, one thing - do you consider exceptions to be part of the api ? Or part of the contract ? I do. And hence I feel that callers should also honor the design of the contract and should be forced to handle the exception, which the designer considers as part of his api. Correct me, if I am wrong, but is this also not design by contract ?Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-20578933405576129252007-07-04T20:11:00.000+05:302007-07-04T20:11:00.000+05:30@Debasish"I would like to force the caller of my a...@Debasish<BR/>"I would like to force the caller of my api..." that's the philosophy I'm against really :-) - checked exception is just the expression of that philosophy on the surface.<BR/><BR/>And the reason is very simple - I can't find any software engineering doctrine that says the callee mandating the caller's logical flow is a good thing. Imagine a language where an API can explicitly define rules for its callers like "you must have an alternate flow to deal with my return value if it's 0,1,or 2." That would sound crazy, but it's essentially the same as checked exceptions in Java.<BR/><BR/>Other languages learned from Java's mistake - C# exceptions are all unchecked, for instance.<BR/><BR/>Cheers.<BR/>-- <BR/>JingAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-22587889.post-27805151755894911992007-07-04T18:32:00.000+05:302007-07-04T18:32:00.000+05:30@Jing:I am not yet a belonger to any specific camp...<I>@Jing:</I><BR/>I am not yet a belonger to any specific camp regarding checked exceptions in Java - I am still wondering .. I see that you are quite clear on your camp :-). In this current context, if I would like to force the caller of my api handle the alternate route of the use case as part of the business rule, what alternatives do I have other than checked exceptions ? This is where I vascillate - those typed api s where the client needs to be enforced into handling exceptional routes.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-81248822599643680462007-07-04T02:00:00.000+05:302007-07-04T02:00:00.000+05:30I think basically it boils down to what philosophy...I think basically it boils down to what philosophy are you using for exceptions. <BR/>I always frowned at using exceptions for control flow (and not sure of the performance implications).<BR/>In your example, you get a ShortPositionException because you're violating the contract. AFAIK if you follow DbC, the caller is responsible to ensure the position is not short before calling update if you're not buying.<BR/>On the other hand, if the domain speaks of exceptions, I understand trying to follow it as close as possible, but I'm not sure that plain Java is the right language to do it...Anonymoushttps://www.blogger.com/profile/17525961934302794120noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-4851695759892830902007-07-03T23:43:00.000+05:302007-07-03T23:43:00.000+05:30Debasish,I agree with you that exceptions, being c...Debasish,<BR/>I agree with you that exceptions, being crucial part of any contract, should be considered part of the domain.<BR/>But when it gets to checked vs. unchecked, <A HREF="http://www.digizenstudio.com/blog/2006/08/08/my-2-cents-on-checked-exceptions/" REL="nofollow">Here's why I have to disagree with you.</A> :-)<BR/><BR/>In short, to me, a method throwing a checked exception is dictating its _immediate_ caller, which is kind of making things going backwards.<BR/><BR/>Cheers.<BR/>-- <BR/>JingJing Xuehttps://www.blogger.com/profile/01002689771296002774noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-5392843632396430702007-06-25T21:28:00.000+05:302007-06-25T21:28:00.000+05:30@Marcos:In that case how do u plan to handle domai...<I>@Marcos:</I><BR/>In that case how do u plan to handle domain exceptions like ShortBalance during Position Updation? I would like the user to force take specific action when I hit this condition in course of the usecase. And my contract should reveal this - hence typed checked exceptions ..Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-4183906436980975212007-06-25T20:50:00.000+05:302007-06-25T20:50:00.000+05:30Debasish: you are confusing domain error flow wit...Debasish:<BR/><BR/> you are confusing domain error flow with application error flow. What about the error flow of the error flow then? <BR/> If the domain expert told you that, then it's not an exceptional condition for you as modeler, it's the way they normally work.Anonymoushttps://www.blogger.com/profile/15563034109557639889noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-84316918382384801292007-06-21T12:31:00.000+05:302007-06-21T12:31:00.000+05:30Hello DebasishFirst, I whant to tell you about my ...Hello Debasish<BR/><BR/>First, I whant to tell you about my apprecation of your blog. It's greate! very informative and useful.<BR/><BR/>But, I can't agree with you about using checked exception in domain. <BR/><BR/>Yes, checked exception are made for "modeling alternate flows". But, Do you shure that it are required for this? I belive that "prevent throw by checking" technic (such we use in Iterator) is more suitable in DDD than amazing throwing/catching.Mikhail.Khludnevhttps://www.blogger.com/profile/12760462625758588434noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-63952769704617113412007-06-20T09:56:00.000+05:302007-06-20T09:56:00.000+05:30I am 100% +1 with Pablo. Modeling alternate flows ...I am 100% +1 with Pablo. Modeling alternate flows of use cases with checked exceptions is a very much practiced idiom in Java. That is what checked exceptions are for! They make your api s robust and express the intent at a level which is much closer to the domain. In the example that I have cited, the domain expert actually told me that when they have a short-position for an account while processing a trade in the back-office, they flag it as an exceptional condition which needs to be treated in a special way. They need extra authorization from the supervisor to determine if the trade should go through considering other factors like collaterals etc.Anonymoushttps://www.blogger.com/profile/01613713587074301135noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-465697782967627982007-06-20T00:33:00.000+05:302007-06-20T00:33:00.000+05:30Hi Pablo. I think Flavio is right. When you model ...Hi Pablo. <BR/><BR/>I think Flavio is right. When you model that kind of situation trhowing an exception, you are mixing the logic of what you want to do with the error logic. It's like a controlled goto. In addition... if you first ask if you can do something and then you do it, there's going to appear the method that is modeling the condition and you are going to capture that piece of knowledge for your domain model. You can use SpecialCase or Specification if you don't like ifs.<BR/><BR/>Regards.Anonymoushttps://www.blogger.com/profile/15563034109557639889noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-78089928043570834832007-06-20T00:12:00.000+05:302007-06-20T00:12:00.000+05:30Handle exceptional but expected situations inside ...Handle exceptional but expected situations inside a catch block never is "clean". Expected things are part of the business, are part of the main flow. In this case, the caller can ask first if the account has money, or can use the Specification pattern, or something else.Flaviohttps://www.blogger.com/profile/00079525880177554182noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-62136614569635840582007-06-19T23:14:00.000+05:302007-06-19T23:14:00.000+05:30I have to disagree with you Flavio, I think checke...I have to disagree with you Flavio, I think checked exceptions are the natural way to express conditions that, while unlikely to happen, have to be taken into account when invoking an operation.<BR/><BR/>Think of the InsufficientBalanceException... how would you let the caller know that there are insufficient funds if you don't throw an exception? Returning null or another flag? That would lead to using ifs to decide the action to take, which, in my opinion, is far uglier than cleanly writting the handler code inside a catch block.<BR/><BR/>Personally, I prefer using checked exceptions to model exceptional but expected flow of events, and unchecked exceptions for unrecoverable error conditions which the caller code can't do anything to handle.<BR/><BR/>My 2 cents.<BR/>Regards,<BR/>Pablo.Unknownhttps://www.blogger.com/profile/02363396511952698472noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-82361836475209396682007-06-19T19:50:00.000+05:302007-06-19T19:50:00.000+05:30In addition...The InsufficientBalanceException is ...In addition...<BR/><BR/>The InsufficientBalanceException is an example that I use when I teach. That kind of exceptions drives to manage the domain logic inside the specific way of managing errors of the language.<BR/><BR/>An account with insufficient balance isn't an error, isn't an exception. Is a possibility inside the logic of the domain and have to be modeled like that. An account trying to do something with insufficient money mustn't break sequence with an exeption.Flaviohttps://www.blogger.com/profile/00079525880177554182noreply@blogger.comtag:blogger.com,1999:blog-22587889.post-85963469685728673732007-06-19T19:03:00.000+05:302007-06-19T19:03:00.000+05:30I'll try to explain this in english. Sorry but I'm...I'll try to explain this in english. Sorry but I'm from Argentina and my english is not very good.<BR/><BR/>The situation of short balance have not to be modeled as an exception. Is a situacion that could happen in the domain. The exceptions are for exceptional things, like illegal states of objects, wrong parameters, etc. So, exceptions named domain oriented, for me, are smell.Flaviohttps://www.blogger.com/profile/00079525880177554182noreply@blogger.com