• 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: 2273
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: 2273
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: 10763
148
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: 2273
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.
 
Acetylsalicylic acid is aspirin. This could be handy too:
the new thread boost feature brings a LOT of attention to your favorite threads
https://coderanch.com/t/674455/Thread-Boost-feature
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!