Java's Checked Exceptions (Was: Few things)

[Nick Sabalausky]

Jascha Wetzel <[firstname]@mainia.de> Wrote:

> Bill Baxter wrote:
> > Or you need to have a slick IDE that parses 
> > everything and figures out for you where various symbols are coming from.
> 
> today's programming practice (and language design, as far as it's 
> concerned) should be able to assume proper tools. many things like this 
> can be tackled with semantics-aware features for editors. another 
> example are complex naming conventions that emphasize type or scope of 
> variables (like hungarian notation).
> what these things have in common is, that they make code less readable 
> by including information that can be obtained in different ways.
> readability depends on the reader. the more familiar you are with the 
> code, the less readable it becomes by additional information. the same 
> holds true if you are only interested in the general function.
> 
> i think, that the more real code looks like pseudo code, the better. i 
> often start programming by writing down pseudo code in the editor. it's 
> easier to mess around with and it isn't as officially separate like an 
> upfront pen-and-paper design phase. after i'm happy with the pseudo 
> code, i add the remaining detail. over and over i'm impressed about how 
> little detail i need to add to make it valid D code. the closer it stays 
> to the pseudo-code stage, the easier it is to maintain and refactor. 
> therefore keeping it that way should be a good thing. if additional 
> information can be gathered from an edit-time parser, it shouldn't be in 
> the code.
> 
> ...sorry for the rant ;)

Sorry to veer so far offtopic, but you've just described one the main reasons I don't like Java's concept of checked exceptions (ie, all of that messy "throws" nonsense). (The other reason is it makes me feel like I've stepped right back into C's world of header file madness.)