Comments on: Descriptive Exceptions http://noopenblockers.com/2009/04/27/descriptive-exceptions/ Fri, 04 Jun 2010 17:10:32 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Professor Jay http://noopenblockers.com/2009/04/27/descriptive-exceptions/comment-page-1/#comment-389 Professor Jay Tue, 28 Apr 2009 01:13:31 +0000 http://notebook.novasurv.com/?p=471#comment-389 I thought about that route as well, almost skipping the flags entirely and just having the exception carry the message key. It felt a bit... dirty, having the presentation logic coupled so tightly to either the backend (who did the validation logic) or the exception itself. The translation layer of flag to message key is a bit annoying, but leaves me with a more warm fuzzy design feeling :) I thought about that route as well, almost skipping the flags entirely and just having the exception carry the message key. It felt a bit… dirty, having the presentation logic coupled so tightly to either the backend (who did the validation logic) or the exception itself. The translation layer of flag to message key is a bit annoying, but leaves me with a more warm fuzzy design feeling :)

]]> By: dgoodwin http://noopenblockers.com/2009/04/27/descriptive-exceptions/comment-page-1/#comment-388 dgoodwin Tue, 28 Apr 2009 00:00:36 +0000 http://notebook.novasurv.com/?p=471#comment-388 Agreed that it's brutal to do a bunch of subclasses for each reason, especially in Java where that usually implies a new file, copyright notice, slew of javadoc, etc. Personally I'd have been looking to avoid that catch/switch/case result though, perhaps with something like a public static final for each of your reasons IS_MISSING, REGEX_FAILS, mapping to the bundle key. (these probably being members on the InvalidChannelName exception class itself) Then you're left with a similar throw and a much simpler catch, your switch and case can go away as you no longer need to define a second mapping for reason to bundle key, it's already in the exception. (unless that's munging your controller and view too much but given that it's not a string to display but rather a key the UI uses, it might be ok) Agreed that it’s brutal to do a bunch of subclasses for each reason, especially in Java where that usually implies a new file, copyright notice, slew of javadoc, etc. Personally I’d have been looking to avoid that catch/switch/case result though, perhaps with something like a public static final for each of your reasons IS_MISSING, REGEX_FAILS, mapping to the bundle key. (these probably being members on the InvalidChannelName exception class itself)

Then you’re left with a similar throw and a much simpler catch, your switch and case can go away as you no longer need to define a second mapping for reason to bundle key, it’s already in the exception. (unless that’s munging your controller and view too much but given that it’s not a string to display but rather a key the UI uses, it might be ok)

]]>