tag:blogger.com,1999:blog-8712770457197348465.post1657541890694105059..comments2024-03-19T05:51:39.935-07:00Comments on Javarevisited: Why Catching Throwable or Error is bad?javin paulhttp://www.blogger.com/profile/15028902221295732276noreply@blogger.comBlogger7125tag:blogger.com,1999:blog-8712770457197348465.post-70975918966021151362015-09-26T22:14:39.581-07:002015-09-26T22:14:39.581-07:00you need to catch Throwable in worker threads else...you need to catch Throwable in worker threads else when all worker threads will be died, no work will be done by app (event processing or application processing). however, incase of error, never catch because even if you do or call System.gc() in outOfMemory case not necessary it will help instead of that app should be stopped once come to know that there is 0 event processingAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-8712770457197348465.post-74059044487481977202014-10-28T05:37:36.051-07:002014-10-28T05:37:36.051-07:00I completely agree on catching Exception and Throw...I completely agree on catching Exception and Throwable are bad, but IMHO I believe there is one particular situation where they could be useful (provided logging and stacktrace are preserved) : serving web pages. Catching a generic Exception/Throwable is bad in pretty much every layer of software, except at the outer most one serving web page. In context of serving pages, it may be cleaner to Nam Lehttps://www.blogger.com/profile/16597473911438749584noreply@blogger.comtag:blogger.com,1999:blog-8712770457197348465.post-4998649599780360642014-03-16T21:38:00.368-07:002014-03-16T21:38:00.368-07:00@Javin another est practices we can have for exam...@Javin another est practices we can have for example as shown below..<br />1 -- Catch exactly the Exception(s) you know how to handle:<br /><br />try {<br /> inputNumber = NumberFormat.getInstance().formatNumber( getUserInput() );<br />} catch(ParseException e) {<br /> inputNumber = 10; //Default, user did not enter valid number<br />}<br /><br />2 -- Rethrow any exception you run into andSARAL SAXENAhttps://www.blogger.com/profile/01084233786047386880noreply@blogger.comtag:blogger.com,1999:blog-8712770457197348465.post-79350349297226021632014-03-16T21:28:35.352-07:002014-03-16T21:28:35.352-07:00@Javin Nice article , Just want to add..Probably t...@Javin Nice article , Just want to add..Probably the most important one is, never swallow a checked exception. By this I mean don't do this:<br /><br />try {<br /> ...<br />} catch (IOException e) {<br />}<br /><br />unless that's what you intend. Sometimes people swallow checked exceptions because they don't know what to do with them or don't want to (or can't) pollute theirSARAL SAXENAhttps://www.blogger.com/profile/01084233786047386880noreply@blogger.comtag:blogger.com,1999:blog-8712770457197348465.post-76219714304884671662014-03-04T01:27:19.611-08:002014-03-04T01:27:19.611-08:00Your example on multicatching is a bit poorly chos...Your example on multicatching is a bit poorly chosen as FileNotFoundException is a subclass of IOException. In this case it is enough to catch IOException as that one will also catch FNFE.<br /><br />The multicatch is ofcourse a nice way to avoid boilerplating multiple exceptions of a different type.Nick Stolwijkhttps://www.blogger.com/profile/16723970786934014182noreply@blogger.comtag:blogger.com,1999:blog-8712770457197348465.post-83911482259520023892014-02-28T19:55:59.207-08:002014-02-28T19:55:59.207-08:00Hello Craig, I agree with you, sometime to keep ap...Hello Craig, I agree with you, sometime to keep application running, you got to something like that, but that should be the last thing to do. I have seen code, where programmer catching SQLException, instead of fixing code, because null value for that variable is permitted and they know that it doesn't exist in database. I mean, many programmer think there job done by catching Throwable/javin paulhttps://www.blogger.com/profile/15028902221295732276noreply@blogger.comtag:blogger.com,1999:blog-8712770457197348465.post-38788176423179036942014-02-28T15:34:50.448-08:002014-02-28T15:34:50.448-08:00I'm sure there's a better way to do this b...I'm sure there's a better way to do this but in android there are certain times when the user may be on an edit screen which causes the soft keyboard to show. If he then navigates to another screen with no edit text the keyboard will stay on the screen. So as a programmer I may tell the screen to hide always hide the keyboard. But it the user is coming from a screen that doesn't make Craig C. Martinhttps://www.blogger.com/profile/14233365808947674548noreply@blogger.com