On Tue, Aug 18, 2009 at 1:31 PM, Michael Neale <[email protected]>wrote:
>
> 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 !).
As Peter Becker suggested previously in this thread, you could use the
Either-type in Scala, or if you are adventurous: use the Box-type in Lift
scala> def foo[T](fun : => T) : Either[T,Exception] = try { Left(fun) }
catch { case e : Exception => Right(e) }
foo: [T](=> T)Either[T,Exception]
scala> def fooResult[T](fun : => T) : String = foo(fun) match { case Left(x)
=> "Yielded: " + x; case Right(x) => "Exception: " + x; }
fooResult: [T](=> T)String
scala> fooResult(10/0)
res0: String = Exception: java.lang.ArithmeticException: / by zero
scala> fooResult(System.currentTimeMillis)
res1: String = Yielded: 1250596147666
Box from Lift has a sligtly different semantics, it has 3 distinct states:
Full
Empty
Failure
while Either only has 2:
Left
Right
>
>
> On Aug 18, 9:11 pm, Peter Becker <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 <[email protected]>
> > >>>> 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 <[email protected]> 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
> >
>
--
Viktor Klang
Rogue Scala-head
Blog: klangism.blogspot.com
Twttr: viktorklang
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
