Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

creating any unimplemented exception

 
Dmitri Christo
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi, I have a couple of quick questions about creating any unimplemented exceptions given in the instructions. Sorry if this is too basic.

The instructions state:
Any unimplemented exceptions in this interface must all be created as member classes of the suncertify.db package. Each must have a zero argument constructor and a second constructor that takes a String that serves as the exception's description.


So for example I create mine like:


Would you say this is enough? I know it is only the bare minimum, but do you think something like this will do? (or did I miss something)

Also, did you find it necessary to add any code in the constructors, or create any helper methods inside the exception class? When a method needs to throw an exception like the above, I have the method logic determine when and if this needs to be thrown, so I didn't put any additional code in the exception class itself.

Finally, when I throw these exceptions in my code, should I usually throw the exception that takes an argument, or the no-arg one? -- Does it really make any difference which one? I find it easier to throw the no-arg kind, but perhaps the one taking an argument would provide more information later from the getMessage() method.

Thanks for your advice.

[ March 24, 2008: Message edited by: Dmitri Christo ]

[ March 24, 2008: Message edited by: Dmitri Christo ]
[ March 24, 2008: Message edited by: Dmitri Christo ]
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy, my buddy.

I think you are in the right path. I myself just added a call to super(message) in the default constructor, passing a default String message. Other than that, you did exactly what I did.

Finally, when I throw these exceptions in my code, should I usually throw the exception that takes an argument, or the no-arg one?


Well, I think it really depends on the situation. I mean, if you need to change the Exception description, call the exception's constructor, passing your message as parameter. That's why I created the default constructor calling super() with a default message. Sometimes I call it and it already has a good description. But, the code of these exception are supposed to be quite simple, so you are indeed in the right path!
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Oh, and also, in the constructor that receives a message, you have to call the superclass' constructor, passing the received message
 
Dmitri Christo
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Bob, good catch there, I almost forgot about the call to super()!
 
Roel De Nijs
Sheriff
Posts: 10662
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Roberto Perillo:

I think you are in the right path. I myself just added a call to super(message) in the default constructor, passing a default String message. Other than that, you did exactly what I did.


a little remark: in the default ctr you could also call this("default message"), instead of a calling to super(message).

in this situation it's not needed, but if you add some logic in the constructor having the message-parameter (e.g. making each message completely upper case), this logic wouldn't be executed if you make call to super(message).
 
Roberto Perillo
Bartender
Posts: 2271
3
Eclipse IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Roel De Nijs:
a little remark: in the default ctr you could also call this("default message"), instead of a calling to super(message).


Yes... you would be calling the constructor that receives a message, then this constructor would call superclass' constructor, sending the message, instead of directly calling the superclass' constructor. Calling directly the superclass' constructor is definitely faster.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic