Comments on: Exception Design and Usability http://www.subbu.org/blog/2005/07/exception-design-and-usability HTTP, REST and some Cycling Tue, 06 Jan 2009 22:26:48 +0000 http://wordpress.org/?v=2.7 hourly 1 By: s http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-65 s Mon, 12 Mar 2007 23:24:06 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-65 wheres my comment? wheres my comment?

]]> By: sudhir nimavat http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-64 sudhir nimavat Mon, 12 Mar 2007 23:22:40 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-64 Ya. agree, i have faced similar problems while working with some of opensource libraries, they just throws unchecked NPE and with out any information and as a developer i had to debug actual code to find out the root of d exception, gud API should never through exceptions without including information. But recently spring is promoting unchecked exceptions wat abt tht? sudhit <a href="http://www.jyog.com" rel="nofollow"><a href="http://www.jyog.com" rel="nofollow">http://www.jyog.com</a></a> Ya. agree, i have faced similar problems while working with some of opensource libraries, they just throws unchecked NPE and with out any information and as a developer i had to debug actual code to find out the root of d exception,
gud API should never through exceptions without including information.

But recently spring is promoting unchecked exceptions wat abt tht?

sudhit
http://www.jyog.com

]]> By: Wouter Lievens http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-63 Wouter Lievens Wed, 04 Jan 2006 06:54:07 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-63 It's called Design By Contract... It’s called Design By Contract…

]]> By: Shailesh http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-62 Shailesh Mon, 29 Aug 2005 23:25:38 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-62 Great point and I agree that I faced such types of problems even in very popular current framework. They need to print proper cause about the exception occured, as we can know in advance [by proper testing and good test cases] that what might can cause an exception in the given code, so it need to be properly documented and traced. Great point and I agree that I faced such types of problems even in very popular current framework. They need to print proper cause about the exception occured, as we can know in advance [by proper testing and good test cases] that what might can cause an exception in the given code, so it need to be properly documented and traced.

]]> By: Abhi http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-61 Abhi Wed, 03 Aug 2005 14:20:10 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-61 So the point made :- <strong>Exceptions should be informative.. </strong> Define User Exceptions based on functional cause.. Should be reported by the interface. And Make the technical cause very obvious with proper messages and not swollowing the original stack trace. So the point made :-
Exceptions should be informative..
Define User Exceptions based on functional cause.. Should be reported by the interface.
And
Make the technical cause very obvious with proper messages and not swollowing the original stack trace.

]]> By: Will Sargent http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-60 Will Sargent Tue, 02 Aug 2005 21:20:51 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-60 Great post. Relevant and absolutely correct. Great post. Relevant and absolutely correct.

]]> By: Subbu Allamaraju http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-59 Subbu Allamaraju Tue, 02 Aug 2005 11:48:40 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-59 In response to Paul Holser's comment - Not sure if you are agreeing or disagreeing. The fact is that, most developers treat this issue quite easy, since it since it is very easy to throw and catch an exception in languages like Java. In response to Paul Holser’s comment -

Not sure if you are agreeing or disagreeing. The fact is that, most developers treat this issue quite easy, since it since it is very easy to throw and catch an exception in languages like Java.

]]> By: Paul Holser http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-58 Paul Holser Tue, 02 Aug 2005 10:28:41 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-58 "Most of us consider exception management one of the simplest issues in programming." Wow, really? IMHO it's more that teams do not take exception handling into account at all when creating systems, rather than teams perceiving good exception handling strategies as vital to a system's design. I sense that most teams perceive exceptions as nuisances that should be dispensed with as soon as possible, postponing and creating development headaches in the interest of short-term coding convenience. “Most of us consider exception management one of the simplest issues in programming.”

Wow, really? IMHO it’s more that teams do not take exception handling into account at all when creating systems, rather than teams perceiving good exception handling strategies as vital to a system’s design. I sense that most teams perceive exceptions as nuisances that should be dispensed with as soon as possible, postponing and creating development headaches in the interest of short-term coding convenience.

]]> By: Marc http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-57 Marc Tue, 02 Aug 2005 01:11:19 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-57 Perhaps you should take this a step further with some more examples of a proper implemented API. Perhaps you should take this a step further with some more examples of a proper implemented API.

]]> By: Björn http://www.subbu.org/blog/2005/07/exception-design-and-usability/comment-page-1#comment-56 Björn Mon, 01 Aug 2005 02:41:20 +0000 http://wp.subbu.org/2005/07/exception-design-and-usability/#comment-56 If you avoid setting your sensor object to null in the last code snippet the compiler will warn you that your object migth not have been initialized. Perhaps it made sense in C but in Java it is best to wait with initialization of objects until they get the value for which they were intended. If you avoid setting your sensor object to null in the last code snippet the compiler will warn you that your object migth not have been initialized. Perhaps it made sense in C but in Java it is best to wait with initialization of objects until they get the value for which they were intended.

]]>