tag:blogger.com,1999:blog-18772002.post8418043644930671346..comments2023-12-06T19:00:46.094+00:00Comments on OSGi Blog: Exception HygieneJürgen Alberthttp://www.blogger.com/profile/02725834158183495837noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-18772002.post-82757832527142841822012-05-04T23:36:12.385+00:002012-05-04T23:36:12.385+00:00If you're in this camp, patch checked exceptio...If you're in this camp, patch checked exceptions out of the compiler. It's far easier.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-18772002.post-19881464813868837302011-03-15T12:29:12.988+00:002011-03-15T12:29:12.988+00:00I think this discussion has run its course.
One a...I think this discussion has run its course.<br /><br />One advice, try it out in a project and see how incredible clean and simple the code body becomes, only after you've done that in a serious project, judge it. Likely you never want to go back.Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-43467459084690411642011-03-14T20:06:55.150+00:002011-03-14T20:06:55.150+00:00The trade-off is between having a) "throws Ex...The trade-off is between having a) "throws Exception" on most methods of your application code and b) nipping the checked exceptions in the bud and having no "throws" in your methods anywhere. And so, in all the rest of your application code, you get away with void foo() { bar(); }<br /><br />As an aside, I also find that one benefit of b) is that I can emit more runtime Unknownhttps://www.blogger.com/profile/13620141859700834098noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-81725813569389789452011-03-14T18:57:22.109+00:002011-03-14T18:57:22.109+00:00I really fail to see why:
void foo() {
try {
...I really fail to see why:<br /><br /> void foo() {<br /> try {<br /> bar();<br /> } catch( Exception e) {<br /> throw new RuntimeException(e);<br /> }<br /> }<br /><br />Can be better then:<br /><br /> void foo() throws Exception {<br /> bar();<br /> }<br /><br />I find the second one a million times more readable ... and imho that is what counts. Less is more, as also Ockhams Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-89560430248120858842011-03-14T14:44:48.219+00:002011-03-14T14:44:48.219+00:00I sympathize with Peter's intentions, but not ...I sympathize with Peter's intentions, but not with the "throws Exception everywhere" approach. <br /><br />Instead of propagating the throws clause, I find it better to catch checked exceptions when I make a calls to the third-party code that declares them. The catch clause wraps and rethrows it as an unchecked exception, preferably with some information about what was going on at Unknownhttps://www.blogger.com/profile/13620141859700834098noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-51912608723866224622011-03-12T14:25:48.747+00:002011-03-12T14:25:48.747+00:00You "hate" API's that throw Exceptio...You "hate" API's that throw Exception because ... you do not want to throw Exception yourself. See what is wrong with this picture? <br /><br />If everybody would just throw Exception <i>nobody</i> would have a problem ... Better, if we could just get rid of checked exceptions altogether.<br /><br />The problem is anybody that forgets to add to throw Exception on an interface methodPeter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-64673482486473808202011-03-12T12:13:35.762+00:002011-03-12T12:13:35.762+00:00I second Dave and Christian here. There's noth...I second Dave and Christian here. There's nothing I hate more than coming across an API riddled with checked exceptions, and most of all *the* Exception. <br /><br />You talk about wasted CPU cycles? I suggest you fire up some example code in Google Caliper and see for yourself how much performance is really at stake here. It isn't 1995 any more.<br /><br />You also mention source code Thomas Ferris Nicolaisen https://www.blogger.com/profile/17464665832399025601noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-72747398752188022472011-03-02T18:18:53.886+00:002011-03-02T18:18:53.886+00:00The problem with "throws Exception" come...The problem with "throws Exception" comes when the method is actually implementing some interface method that is not declared with "throws Exception". This is often annoying in callback interfaces like this:<br /><br /><br />interface ResultComputer {<br /> Object computeResult(Object param);<br />}<br /><br />ResultComputer rc = new ResultComputer() {<br /> public Object Unknownhttps://www.blogger.com/profile/06709773379819963791noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-16439840722214011912011-03-02T14:27:21.343+00:002011-03-02T14:27:21.343+00:00@Christian: After some more thinking. Throwing Exc...@Christian: After some more thinking. Throwing Exception is exactly the same burden as throwing SomeOtherException, the caller has to handle the exception (or be clever and let it bubble up). So it is not as if you're doing something highly uncommon ... You make it sound worse than it is.Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-56408071611675344372011-03-02T14:24:04.378+00:002011-03-02T14:24:04.378+00:00@Christian: I do not think that adding to the exis...@Christian: I do not think that adding to the existing virality is making things that much worse ... They should just do the same thing.Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-73358735233168682512011-03-02T12:34:16.173+00:002011-03-02T12:34:16.173+00:00The problem with throws Exception is that it is vi...The problem with throws Exception is that it is viral. So if I use it and someone calls my code then I force him to do the same. So if most of my code does not have to deal with checked exceptions then I only have very few places where I have to do the conversion. The rest of the code is then clean of checked exceptions.Christian Schneiderhttps://www.blogger.com/profile/15483626935577725409noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-7043779302918395802011-03-02T07:39:18.587+00:002011-03-02T07:39:18.587+00:00@Dave: Yes, you're right. It is not a beauty b...@Dave: Yes, you're right. It is not a beauty but it makes the code much smaller, and thus more readable. And as I argued, more robust. I am not talking saving some small crumbs here.<br /><br />@Christian: Well, you're basically wasting CPU cycles and source code real estate to achieve what a simple declaration of "throws Exception achieves." And you still create an indirection Peter Krienshttps://www.blogger.com/profile/11373850803487010328noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-31136438369630713392011-03-02T07:00:18.402+00:002011-03-02T07:00:18.402+00:00When handling exceptions I follow the style that s...When handling exceptions I follow the style that spring uses. For my own exceptions I only used RuntimeExceptions. If I do not think the exception needs to be catched I use a simple RuntimeException. Later I can still create a special RuntimeException class if someone needs it. <br /><br />With checked exceptions outside my code I deal like spring does. I convert them into RuntimeExceptions whereChristian Schneiderhttps://www.blogger.com/profile/15483626935577725409noreply@blogger.comtag:blogger.com,1999:blog-18772002.post-9993805804150069152011-03-01T22:04:49.048+00:002011-03-01T22:04:49.048+00:00Hi Peter,
I may not have interpreted this post co...Hi Peter,<br /><br />I may not have interpreted this post correctly, but it sounds like you're advocating this sort of API:<br /><br />interface Foo {<br /> void doStuff() throws Exception;<br />}<br /><br />I guess this also implies that every method between doStuff() and the entrypoint must also declare "throws Exception"...<br /><br />I don't know if it's just my davehttps://www.blogger.com/profile/08872088478657058117noreply@blogger.com