 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Java Forum / General / April 2006Need of exception handler in calling function, isn't it weird???
Hi, I have written a function as follows public String fetchName(String query) throws Exception { stmt = con.createStatement(); ResultSet rs = stmt.executeQuery(query); rs.next(); return (rs.getString(1)); } I've handled the for exceptions here using "throws Exception". Inspite of that when i call it from other function and in that funtion no exception need to be handled, compiler gives errror. Following is the calling funtion public String checksubAction(String action) { String retValue=" "; String query=""; query = "select Title from dbo.Folder where Folder_Id="+folderId; retValue = dataBaseObj.fetchName(query); } but when i write it in try-catch block, no errror is given. Why is it that inspite of handling exception(s) in the called function, we need to handle them in calling functions. Thanks Hi, what you are realizing is the expected behaviour of exceptions: In opposite to error-codes which can easily be ignored (causing much havock and hard-to-debug errors), the compiler tries to make it harder for you to ignore an error and to continue as if nothing happend. I suggest reading some tutorial on exception-handling. It is not soo difficult. Ciao, Ingo > Hi, > [quoted text clipped - 3 lines] > harder for you to ignore an error and to continue as if nothing > happend. Devil's advocate says: nah, it's easy to ignore an error; that's what empty catch blocks are for!  Signaturemonique Help us help you: http://www.catb.org/~esr/faqs/smart-questions.html > Devil's advocate says: nah, it's easy to ignore an error; that's what > empty catch blocks are for! Noooo!! People will see you. Put an innocuous-looking return in a finally block. Nobody uses -Xlint. Tom Hawtin SignatureUnemployed English Java programmer http://jroller.com/page/tackline/ >> Hi, >> [quoted text clipped - 6 lines] > Devil's advocate says: nah, it's easy to ignore an error; that's what > empty catch blocks are for! For me - Checked Exceptions are a pain in the a.s. I tend to wrap them in unchecked exceptions asap. Hi, > For me - Checked Exceptions are a pain in the a.s. Sometimes they are, yes. But... > I tend to wrap them > in unchecked exceptions asap. ...where (on which level) do you catch the uncecked exception, then? This can be even more pain! Ciao, Ingo > Hi, > [quoted text clipped - 10 lines] > Ciao, > Ingo I'm not dishing exceptions, they are much better than error codes for all of those good reasons we know. However, I favour the 'write exception safe code' method, that is, dont use or limit there use where possible. For example, we could simply write a for loop with an incrementing int until we get an OutofBoundException from the colloection, but we dont, we either use iterators or loop while the index (int) is less than the collection size. On those occasions where exceptions make sense, I make sure each layer within the applications only expose their exceptions, not lower layer exceptions. This means wrapping lower layer exceptions within new ones. These new ones then add more context information to the lowlevel exception. Simplistic E.g. a low level DB Exception - DBConnectionRefusedException("SQL: db not contactable or offline - error code 1234") Which would be wrapped by the model layer - DatabaseConnectionFailureException("Unable to connect to Database (MySystemDatabase)"); Hi, > On those occasions where exceptions make sense, I make sure each layer > within the applications only expose their exceptions, not lower layer > exceptions. This means wrapping lower layer exceptions within new ones. > These new ones then add more context information to the lowlevel > exception. Yes, that's how it is supposed to be. But my question is: why do you want to wrap them in a *Runtime*Exceptions? I think that makes it more difficult to decide where to catch it (because the layer above does not necessarily know that this exception is thrown)! Ciao, Ingo <parkarumesh@gmail.com> wrote... > Hi, Hi! > I have written a function as follows > > public String fetchName(String query) throws Exception [snipped] > I've handled the for exceptions here using > "throws Exception". Nope, on the contrary. "throws" is a construct which tells us that this method *doesn't* handle Exception. Hence, any Exceptions that occur that need to be handled are "forwarded" to the calling method. The calling method in turn can handle or throw the Exception, etc... // Bjorn A so Bjorn if i write the code of called function in try-catch, i won't have to write try catch in the calling function? <parkarumesh@gmail.com> wrote... > so Bjorn if i write the code of called function in try-catch, > i won't have to write try catch in the calling function? Yep. You can either... -------------------------- public void called() throws Exception { ... } public void calling() { try { called(); } catch (Exception ex) { // handle it here... } } -------------------------- ...or... -------------------------- public void called() { try { ... } catch (Exception ex) { // ...you can handle it here... } } public void calling() { called(); } -------------------------- However, I suggest you follow Ingo's advice, to read up on Exception handling, as there are more details worth to know about it. You shouldn't make a "catch-all" handler for the supertype Exception, but try to discriminate between the Exception types, and handle them according to what type of Exception it actually is, e.g. SQLExceptions handled in one way, other Exceptions in other ways... // Bjorn A Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.