I still believe that the main reason people hate checked exceptions is
that they have been used badly.
But I don't really like them either, I just dislike runtime exceptions
more ;-) The reason for that is that they hide things I might want to
know about when using an API. No one reads documentation well enough,
the enforcement checked exceptions give you is quite useful -- at least
given the context of Java. And I don't buy into the "just unit test"
argument, things like SQLException and IOException rarely happen in test
environments unless the test was designed to test just that -- it is the
exceptional case you don't expect that scares me.
What I would really like to see is a meet/or/disjunction/union operator
in the type system, with a case-like construct to resolve the resulting
types. Scala has two things that are halfway there (Either, case
classes), but neither is the full monty.
Peter
phil swenson wrote:
> there is a reason no other language ever written has checked
> exceptions - checked exceptions are a bad idea.
>
> On my first java project back in 1999 I remember adding in a checked
> exception to a utility class. It has effects on hundreds of classes
> and 1000s of method calls. I then decided it was more trouble than it
> was worth and switched everything to runtime exceptions. Worked
> brilliantly.
>
> Checked exceptions almost always degenerate into "throws exception" on
> 100s to 1000s of methods in your project. They simply don't scale,
> one small change can ripple through an entire project. They also lead
> to try{blahblah}catch(Exception e}{} (exception hiding). They lead to
> logging the exception multiple times (catch, log, rethrow), giant
> method signatures, exception wrapping, and other harmful practices.
>
> The correct (IMO) way to handle it is to let the exception bubble up
> to the top level thread and handle it there, whether it's present to
> the user, log, and/or cancel a transaction. Exceptions almost never
> can be recovered from and people are almost always fooling themselves
> if they think they can. I think 95+% of the time exceptions are from
> bugs, not from recoverable situations. People try to build hugely
> fault tolerant systems and they end up hiding bugs.
>
> In the rare case that you want to handle an exception at a lower
> level, do it. But you certainly don't want this to be the default
> behavior, it's the EXCEPTIONAL case. :)
>
>
>
> On Aug 17, 9:10 pm, Michael Neale <michael.ne...@gmail.com> wrote:
>
>> What do people think of the scala approach of no checked exceptions -
>> even checked exceptions are not treated specially by the constructor
>> (personally, I like it).
>>
>> On Aug 18, 12:55 pm, Christian Catchpole <christ...@catchpole.net>
>> wrote:
>>
>>
>>> No, i just let that go up. I really try to avoid the declare as null
>>> then set thingy.
>>>
>>> On Aug 18, 12:03 pm, Casper Bang <casper.b...@gmail.com> wrote:
>>>
>>>> You neglect to handle the checked exception declared by
>>>> prepareStatement no?
>>>>
>>>> PreparedStatement stmt = null;
>>>> try{
>>>> stmt = connection.prepareStatement(sql);
>>>> final ResultSet rs = stmt.executeQuery();
>>>> try{
>>>> while (rs.next()){
>>>> // Stuff...
>>>> {
>>>> }
>>>> finally{
>>>> rs.close();
>>>> }}
>>>>
>>>> catch(SQLException e){
>>>> // Logging...}
>>>>
>>>> finally{
>>>> try{
>>>> stmt.close();
>>>> }
>>>> catch(SQLException whoTheFuckCares){
>>>> };
>>>>
>>>> }
>>>>
>>>> Really, how many other ways are there to do it I wonder now? (Apart
>>>> from wrapping certain things, like the last try-catch clause in some
>>>> general purpose "closer util"?).
>>>>
>>>> /Casper
>>>>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
