• Post Reply Bookmark Topic Watch Topic
  • New Topic

Which way to go - A design question.  RSS feed

 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi all,
this is not a problem i face but a design question i would say. please try to help me here if i am missing any important consideration.
i have observed two ways for implementing methods that have chances of running into exceptional conditions and also has return values on success,
please analyse both the below options in terms of usability,
1.
General convention...

2.
Use of "output" parameters

you see the difference between two methods??
btw, i want to consider this w.r.t. APIs we develop you know where there will be a third party accessing this API methods..
here is my thinking of two approaches,
1st one:
--------
in exceptional conditions we throw Exception hence the application using it will have to catch it
OR
if its runtime exception then it depends upon how that third party application is handling those exceptions if we are not handling those possible runtime exceptions like NullPointerException or something and wrapping those in our application specific exceptions and then re-throwing them...
e.g. if can check,
if( inputVariable == null ) {
throw new Exception("Null Input is not allowed");
}
even before NullPointerException occurs...
and if we want to have Exception types defined by our application we need to create appropriate exception classes and then throw object of one of those classes...
2nd one:
--------
what we do is, if we catch an exceptional condition then we return the "false" value to the application and set error property of the object.
so, now it becomes responsibility of the third party application to check the return code for the method myMethod() and take action according to that status code like,

in this case client code doesn't have to use try{} catch{} thing and so we can get rid of that overhead i guess..
also this 2nd approach is useful in certain scenarios when we have to return multiple values of different types. e.g. if we want to return two values- one of String type and one of int type then it would be problem using 1st approach because we might have to create intermediate object to hold both those values and then return that object. i.e. we can have a object like,

and return that from myMethod()....
but if we have used the 2nd approach then we can just have StringBuffer and Integer objects as myMethod()'s output parameters and do the stuff...
(did you notice I used StringBuffer and Integer in place of String and int?? )

well, we can certainly argue that we can't simply pass int or String as output arguments to myMethod() as we can't get them back if you know what i mean...and so that would involve equal amount of work that we do in creating object of specialReturnValue and then return it...
(though, we can't probably use mixed approach in API we develop because that would cause inconsistency...)
so..as you see there are pros/cons of these approaches please throw some thoughts and important issues i might have overseen in this....

regards,
maulin
 
karl koch
Ranch Hand
Posts: 388
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi
for me its number one to go...
Exceptions are there to notify that something went wrong. thats it.
also i dont see how you will get the results out of the methods if you use approach number two. you ever tested this ? and even if it works you would need to check the error flag. how do you guarantee that the third party will check the flag. you cant. an exception must be catched (it can be ignored then....but the compiler will tell that there is exception to catch).
k
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Karl,
yes. i tested the 2nd approach fully. i have it running in one of the api i wrote but i thought it to be much detailed to put down here, which might diversify the purpose of the topic.

so, your comments points out important thing,
"if we want to FORCE third party applications to make sure they are aware what they are doing then 1st approach is the way to go. definitely."
but the point you said that "they have to catch exception" is not quite agreeable because what if third party writes like,
try {
myMethod();
} catch(Exception e) {
// don't do anything
}
in this case they explicitly ignored what we tried to impose so actually we can't FORCE them to take any action even if we throw the exception, right?
it sounds similar to 2nd approach where users don't check the return code. or does it not?
i'm not in favor of any of the approaches in particular but i'm just trying to explore things you know.
btw, i didn't want to sound MS guy so i didn't raise this point earlier but here is what i have observed- in many MS applications (that my friends develop) they use 2nd apporach most of the times and actually thats what induced me to pose this question in here...
and if we think in terms of C language (where we don't have Exception handling) then 2nd approach sounds better- actually thats the only option we have- as atleast we have some way of notifying error (as far as we return int error code instead of boolean)..but that might again raise issue that "thats the very reason we have Exceptions in Java to enable better user handling of errors"...
it seems all arguable
thanks. your comment is certainly a point to note.
lets keep this rolling.
regards
maulin.
 
gautham kasinath
Ranch Hand
Posts: 583
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Howdy!
I believe you can take a look at the discussion in the same lines in JDC :
http://forum.java.sun.com/thread.jsp?thread=259961&forum=4&message=978879
or if you want a clearer picture of error and exceptions :
http://www.developer.com/java/article.php/1455891
Well, after going thru this same question a way long back. I learnt that if I do not want my API users to not know what went wrong completely and didnt want them to recover from what hit them, I would use Error. But if there was something really crutial that the method was doing ( but not as crutial as error ) and I felt that calling method or object needs to know this, for its further functioning. then I would go for an Exception. But I would always make sure the exception that I generate is in line with those generated by other APIs that I use in turn. But better documented.
I would veto the 1st approach.
Regds
Lupo
 
Maulin Vasavada
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi gautham,
great! exactly the discussion i wanted.
everybody else also refer to this link of JDC instead of "repeating" the cycle of thoughts (of course i would recommend re-usability in this case as well :-))
and thanks to gautham.
regards
maulin
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!