Removal of Checked Exceptions
Since we've been on the topic of future changes to Java ... does anyone else get frustrated when the little Anders Florgenborgenites start with their C# preachiness:
"Java needs to get rid of checked exceptions, because C# doesn't have them!"
[sarcasm]
I mean, he did make a good point when he said: "Everybody just writes:
try { .... } catch (Exception e) { }.
Nobody ever handles exceptions, so why do we need them?"
[/sarcasm]
(Those retarded "properties" thingies will be left for a later discussion...)
My sychophantic personality is suffering from these discussions. Usually I know to agree with the big boys, but now they're arguing amongst themselves, I don't know what to think.
For me, could you please reach consensus on issues like closures, operator overloading, checked exceptions and whether it's okay to eat meat on fridays.
On a serious note, what's wrong with properties?
>> I mean, he did make a good point when he said: "Everybody just writes:
hmm, haven't done that (except in a few cases where the exception is expected like in testcases and in those cases I comment my decision) in years...
At the very least the exception is logged and rethrown as an application specific exception. Usually more is done (if possible).
His entire "proposal" (which springs from the problem he has reconsiling checked exceptions and closures btw, he can't find a way to create closures that throw checked exceptions therefore checked exceptions should go to make place for closures, which we've already decided in that other thread are pretty much useless) is flawed.
Just because some people don't know how to use something properly we should prohibit that thing being done at all? And that combined with wanting something introduced that will be abused badly to replace something else that's also abused but has less potential for abuse than the new stuff he wants?
Properties: goodClosures: probably goodChecked exceptions: goodOperator overloading: bad, unless very tightly controlledThese are just my opinions, and anybody is of course free to disagree and be a wrong heathen *******.
> we've already decided in that other thread are pretty much useless...Not really, no.~
> Just because some people don't know how to use
> something properly we should prohibit that thing
> being done at all?
So would that be your stance on operator overloading ? ;-P
On a more serious note I would say that checked exceptions are great, as it allows you to deal with issues sooner rather than later, not to mention being aware of them right away.
> > we've already decided in that other thread are> pretty much useless...> > Not really, no.> I guess it depends on who he means by "we". I'm certainly not part of that "we".
Notwithstanding my well known bias against anything involving the word Microsoft (C# is a huge stinky pile of bat guano that doesn't even make good fertilizer or black powder but that's another story) checked exceptions are an exceptionally (pardon the pun) strong means for handling concerns and out of flow occurances in code. The problem is that entirely too many people do not take the most basic steps of properly handling or managing exceptions and so end up with a frightening amount of ...
try{
// do something here
}
catch(Exception e){
e.printStackTrace() ;
}
that swallows the exception because they don't really know what if anything they can do about the problem. Just because C# has training wheels doesn't mean I'm going to put them on my Ducatti ...
PS.
> I guess it depends on who he means by "we". It means ussss, my precioussss.~
> The problem is that entirely
> too many people do not take the most basic steps of
> properly handling or managing exceptions and so end
> up with a frightening amount of ...
>
> > try{
>// do something here
> catch(Exception e){
>e.printStackTrace() ;
>
>
This is why good inteview questions, coding standards, and code reviews are essential. It's certainly not an argument against checked exceptions. (I know you're not presenting it as anti-checked, but some might interpret it that way, and I think I've seen it presented that way.)
Absolutely I am not presenting it as anti-checked exceptions, quite the contrary. What I'm saying is that the problem is not with the platform rather the problem is with developers who through a lack of understanding, or pure laziness can't be bothered to use the capability of checked exceptions properly.
PS.
I'm right there with you. Hallelujah, brother!
I'm so glad I'm not alone on this one... (checked exceptions)As for properties, I'm not entirely against them. I've just seen them abused so very badly that I can't help but dislike them. (That, and I have no problem typing three extra letters ... i.e. get/set).
> I'm so glad I'm not alone on this one... (checked
> exceptions)
> As for properties, I'm not entirely against them.
> I've just seen them abused so very badly that I
> can't help but dislike them.
I've never used them, only read about them. From what I've read, they seem good in principle. But I could see where they'd be easily abused.
> (That, and I have no
> problem typing three extra letters ... i.e. get/set).
It's not the three letters I care about. It's that I like the notion of elevating this construct to the language level, rather than relying on naming convention or libraries.
I am slowly getting more and more into (hopefully) using exceptions properly, but it seems to be one of those things that is a bit of a black art. I would assume that normally one determines what to do with exceptions based on past experience, but where does one start when they have limited to no experience ? I know for me personally I looked around lots and started to use them to what seemed to make sense at the time. Hopefully that is the proper manner in which to go about it. I understand how they work, but the finer details of when should you throw an exception or work with it sometimes seem quite difficult. ( Not likely a lot that you guys can offer on the situation, and I suspect that is where mentoring programs would be quite handy but if anyone knows of books that give general ideas possibly even with subject examples I would be greatful ).
Sorry about the horrible run on sentence, it's friday afternoon and my brain has almost shut off
> I've never used them, only read about them. From what
> I've read, they seem good in principle. But I could
> see where they'd be easily abused.
>
>
> > (That, and I have no
> > problem typing three extra letters ... i.e.
> get/set).
>
> It's not the three letters I care about. It's that I
> like the notion of elevating this construct to the
> language level, rather than relying on naming
> convention or libraries.
There is one beautiful thing about them ...
ArrayList<String> mystring = new ArrayList<String>();
mystring.add("String A");
mystring.add("String B");
mystring.add("String C");
// this would be legal in C#:
String test = mystring[0];
Also ...
HashMap<String, Object> map = new HashMap<String, Object>();
map.put("First", new JTable());
map.put("Second", new JTable());
// legal in c#:
JTable t = map["First"];
Don't know why, but I just like that so much better ... (one of the few instances, though...)
