On Aug 21, 4:46 pm, B Smith-Mannschott <bsmith.o...@gmail.com> wrote: > Checked exceptions *are* a failed experiment.
My first experience and after reading Joel's post I was thinking that but previous posters convinced me that this is not necessarily true - but I think there lies some truth also in your comparison with communism. BTW: I find the checked exceptions more useful than the unchecked exceptions (for using in my own code). > Some have argued that there's nothing wrong with checked exceptions, > per se, it's just that people don't use them right. The question is: How really to use them right? I think this is a desired result of this discussion. :-] > Joel's article, I can't really agree with, though it's a pretty old > post. Exceptions as an alternate form a control flow have their place. The ten commandments are also very old posts - information or thoughts do not necessarily become less important with increasing age. ;-) - I cannot say that I completely agree with everything in that post, but the point that completely fits my experience is the decreased readability. > I wish Java had a good way of dealing with partial functions (i.e. > functions that can't return a sensible value for all possible inputs). > The only options we seem to have are: throw an exception or return > null. Java's null is a mess. (Though sometimes the Null Object Pattern > can help here.) Languages with a Maybe type (e.g. Scala) are > appealing. Never heard of the "Maybe" type - but I am pretty sure that a "Maybe" would be the last thing I would like having to deal with. I like in Python that a function can return multiple values, but something similar can be achieved in Java returning objects. Imagine to return an object that contains a return value + your data. However, if you have very different return types you would need many different new classes encapsulating all the combinations. In the past (even before using Java) I have used a common accessible error object (containing status information and error/warning message lists) - a static one accessible from and for all levels within my application. So my functions can return a value or null and if they produce an error they tell this separately. An advantage is that whoever interested can investigate current error status and a disadvantage is that you have to be careful when to reset error status. But I have used this method quite successful for many years prior using Java. I have started implementing something similar for my Java projects and I think I can improve this method further. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
