Martin Wildam wrote: > On Aug 21, 2:07 pm, Peter Becker <peter.becker...@gmail.com> wrote: > >> I take the point that it is possible to make code harder to read using >> exceptions in a way that is not possible without. I must admit I didn't >> really think it through when I read Joel's blog post. >> > > I think the reduced readability is the core disadvantage of using > Exceptions. > And I think that it is easier to create buggy code with exceptions - > especially for beginners. > (I know that most of those doing Java do it since a long while but > they get older and junger people must somehow follow them). > In my experience beginners hardly ever think of the exceptional cases to begin with ;-)
The reduced readability is IMO not really applicable either, since I don't see many beginners writing complex code in a neat fashion like your example. And an experienced Java programmer shouldn't write the big bit of code where the exception just bubbles out. >> There is the opposite danger, though: ignoring a return value. Since >> C-like languages allow functions to be called as statements, it is >> pretty easy to just ignore the fact that there is an error code >> returned. Checked exceptions force you to deal with the issue. >> > > Whether it is an exception or a return code you always can drop it or > deal with it. When I use a method like openFile or something the first > thing automatically is to look for a return code. > But is that true for your average Joe Java? > >> Of course that problem could also be fixed by disallowing calling >> functions as statements, which I think would be a good idea not just for >> this reason. >> > > I would loose then the option to ignore the result which may make > sense (e.g. loading an optional configuration file). > People want closures, annotations and all the like but then I should > get limited how to use a simple method? > Anything that has a return value that can be ignored seems suspicious to me. Arguably in Javaland you couldn't enforce such rule without some option of ignoring it in places, but I'd quite like at least a compiler warning with matching @SuppressWarning. For me an ideal system would have functions that are SEF and procedures that never return anything. But I'm a bit of a purist sometimes. Peter --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to javaposse@googlegroups.com To unsubscribe from this group, send email to javaposse+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
