Reinier Zwitserloot wrote:
> Yes, an utopia with checked exceptions is probably pretty decent, but
> as a practical matter they've been horribly abused. Not just by third
> party libraries; the java core library is inconsistent in places and
> has a lot of missing throws clauses in interfaces that can't be fixed
> because it would break backwards compatibility. Trying to fix these
> things is going to be even more painful than having to deal with
> checked exceptions in the current circumstance, which is one of the
> reasons why I advocate solving the problem directly. Such as offering
> an opt out mechanism where a programmer can explicitly 'correct' the
> compiler to say: Yah, I know, I know, this method call here DECLARES
> that it'll throw SomeCheckedException, and I neither catch it nor
> declare to throw it onwards, but, shaddap. I know what I'm doing, just
> compile this code, and let me get on with my day.
>
> It'll be abused, but the notion that exceptions will be abused in some
> fashion is what we have to deal with. The question is: How can we make
> sure the abuse is kept to a minimum? I'd assert that try {} catch
> ( Throwable t ) { Log.log(t); } is a much worse abuse than
> sneakythrowing.
>
Agreed.
> You get the benefit of being explicitly told about the checked
> exceptions that you ought to be checking, but when the theory fails
> due to a practical matter (the declared exception can't possibly
> happen, or you want to throw the exception onward but due to a badly
> designed interface you're not allowed to, etc, etc), you won't have to
> jump through a bunch of hoops, obscuring the exception as you go.
>
> Being able to return a disjoint type so you can cover extraordinary
> exit conditions that way instead of throwing exceptions for them could
> work, but I don't really know of any language that handles them all
> that well. The only way I can see how it could possibly work is
> pattern matching. Which scala can mostly do, can't it?
>
As far as I understand you can't just do something like this (in
Java-like syntax, but ignoring a few other things Java such as the
.class for types):
public Result|Error1|Error2 someMethod() {...}
public void someOtherMethod() {
var result = someMethod();
switch(typeof result) {
case Result:
processResult(result);
default:
handleError(result);
}
}
public void processResult(Result result) {...}
public void handleError(Error1|Error2 error) {
...code using anything on common supertypes of Error1/2...
}
Part of what I'd like to see is that there is no need to name the types
used. The signature of the last method should also be allowed to be
handleError(Error) assuming that both Error1 nad Error2 are subtypes of
Error (which is really just normal polymorphism since it implies that
the union is a subtype, too).
My Scala is not good enough to judge what is truly possible, but most
code I've seen seems to end up using Either in this case, which seems a
bit of a kludge -- particularly if you create a union of more than two
types. I'd be happy to hear about alternatives.
Peter
> On Aug 18, 12:13 pm, Peter Becker <peter.becker...@gmail.com> wrote:
>
>> 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
-~----------~----~----~----~------~----~------~--~---
