catch generalization

Can anyone propose a reason it would not be a good idea to generalize
catch to accept a PartialFunction[Throwable,T] ?

Since the current syntax requires braces and a series of case
statements, all existing code would work as is.  This would open the
door to all sorts of appealing options, including ad hoc composition of
catch logic, implicits from OtherThing => PF[Throwable,T], the whole kit
and caboodle.

BTW I noticed later that something similar to the try/catch/finally
encapsulation code I sent is already in the source tree, in ScalaRunTime:

 abstract class Try[a] {
   def Catch[b >: a](handler: PartialFunction[Throwable, b]): b
   def Finally(handler: Unit): a
 }

 def Try[a](block: => a): Try[a] = new Try[a] with Runnable { [...]

And some code like scala.runtime.ExceptionHandling:

 public abstract class ExceptionHandling {
   public static Throwable tryCatch(Runnable runnable) { [...]

...although that's in java and looks like it might only exist because
the msil target handles exceptions differently.

I can't see of any of it being used anywhere, is it? Since it's already
in there I think we should polish it up and use it.

--
Paul Phillips      | A Sunday school is a prison in which children do
Imperfectionist    | penance for the evil conscience of their parents.
Empiricist         |     -- H. L. Mencken
all hip pupils!    |----------* http://www.improving.org/paulp/ *----------

In the early days of Scala (version 1.x), exception handling was not
implemented in the compiler. Instead, it relied on calling runtime
methods like the ones you suggest, with the relevant exception handling
written in Java (this explains the relics you discovered).

In version 2.x we rewrote it mainly for performance. I don't remember if
we did any measurements, probably we assumed it is faster. If you want
to make these changes, it'd be nice to know how much we lose/gain in
terms of speed/code size.

The change wouldn't be difficult, but not trivial either. The exception
handling implementation is quite intricate and I'd like to see it gone,
if this change goes through. The translation to call runtime methods
instead needs to be done in a manner that allows phases to generate
try-catches after parsing in the pipeline (for instance, to implement
non-local returns). Probably 'synchronized' should be implemented in a
similar manner.

So far, the argument in favor of this change is language and compiler
simplification, and more composable error handling. The downside is
additional work and possible performance degradation. I also wonder how
well type inference would work, and if there's ever a need to explicitly
write the expected type. If performance is really a problem, the
exception handling logic could be kept, and use it whenever the 'catch'
argument is a partial function literal (the common case), and use
higher-order functions elsewhere. But that would complicate instead of
simplify the implementation.

Maybe this could be a SIP?

cheers,
Iulian

Paul Phillips wrote:
> Can anyone propose a reason it would not be a good idea to generalize
> catch to accept a PartialFunction[Throwable,T] ?
>
> Since the current syntax requires braces and a series of case
> statements, all existing code would work as is. This would open the
> door to all sorts of appealing options, including ad hoc composition of
> catch logic, implicits from OtherThing => PF[Throwable,T], the whole kit
> and caboodle.
>
> BTW I noticed later that something similar to the try/catch/finally
> encapsulation code I sent is already in the source tree, in ScalaRunTime:
>
> abstract class Try[a] {
> def Catch[b >: a](handler: PartialFunction[Throwable, b]): b
> def Finally(handler: Unit): a
> }
>
> def Try[a](block: => a): Try[a] = new Try[a] with Runnable { [...]
>
> And some code like scala.runtime.ExceptionHandling:
>
> public abstract class ExceptionHandling {
> public static Throwable tryCatch(Runnable runnable) { [...]
>
> ...although that's in java and looks like it might only exist because
> the msil target handles exceptions differently.
>
> I can't see of any of it being used anywhere, is it? Since it's already
> in there I think we should polish it up and use it.
>
>