Proably would use a set of case classes I guess, but would end up
looking like a pretty version of that (someone like Viktor will
probably show us !).
On Aug 18, 9:11 pm, Peter Becker <peter.becker...@gmail.com> wrote:
> 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
-~----------~----~----~----~------~----~------~--~---
