Re: Exception handling

  I'm with you 500% that checked exception has produced
awfull APIs in java.

 Now I read :

>>Checked exceptions via a plugin are
>>planned, but currently unimplemented.

 Why would anyone write a plugin and bring this plague into Scala ?


On Thu, Sep 3, 2009 at 1:05 PM, Ricky Clarkson <ricky.clarkson@gmail.com> wrote:

I would suggest using exceptions for cases that you *aren't* going to
programmatically handle, i.e., throw, but don't catch, and using
Option/Either/whatever you like for other cases.

Please note that this is my opinion (and that of some others), and not
any "this is the Scala way".  Checked exceptions via a plugin are
planned, but currently unimplemented.

If you're desperate, I expect it wouldn't be too difficult to write a
bytecode analyser that looks for missing throws/catches, except in
cases where type parameters are involved.

Note that checked exceptions are quite a problem in most Java code.  I
estimate that 90% of all catch blocks I see in Java code are written
badly (empty, swallow the exception just giving the message, log to
debug level instead of warn/error, etc.).  It's certainly not clear
that checked exceptions, at least as Java does them, are a good thing.

Here, have some Java:

   private byte[] blowfish( byte[] input, byte[] key )
   {
       byte[] initialisationVector = createInitialisationVector( nda );

       try
       {
           final Cipher cipher = Cipher.getInstance(
"Blowfish/CFB/NoPadding" );
           cipher.init( Cipher.DECRYPT_MODE, new SecretKeySpec( key,
"Blowfish" ), new IvParameterSpec( initialisationVector ) );
           return cipher.doFinal(input);
       }
       catch ( InvalidKeyException e )
       {
           throw new RuntimeException( e );
       }
       catch ( InvalidAlgorithmParameterException e )
       {
           throw new RuntimeException( e );
       }
       catch ( NoSuchAlgorithmException e )
       {
           throw new RuntimeException( e );
       }
       catch ( NoSuchPaddingException e )
       {
           throw new RuntimeException( e );
       }
       catch ( IllegalBlockSizeException ex )
       {
           throw new RuntimeException( ex );
       }
       catch ( BadPaddingException ex )
       {
           throw new RuntimeException( ex );
       }
   }

2009/9/3 Job Honig <joho@xs4all.nl>:
> Hi All,
>
> I have a question about dealing with exceptions.   In my Java software,
> exceptions have always played an important role in my architectures,
> and I made a point of thinking where and how to handle them.
>
> Now I don't see how to accomplish this without a compiler that helps
> me to track exceptions that might be thrown; to do that by hand is not
> easy.  And I obviously don't want my exceptions to go unhandled and
> have them thrown to the outside world.
>
> Can I do exactly the same as in Java with the @throws annotation?  I
> wonder...   At http://www.scala-lang.org/node/106 I read:
>
>> Since Scala has no checked exceptions, Scala methods must be annotated
>> with one or more throws annotations such that Java code can catch exceptions
>> thrown by a Scala method.
>
> I can't do that properly, of course, because in order to do it I would need
> the same kind of support as Java throws clauses  offered me in the first
> place.
>
> Are the @throws clauses just an interface to Java, or are they really
> the same as the Java throws?  And how do I know what @throws I
> need if the compiler doesn't tell me in the first place?
>
> How do you guys solve this problem?  Are there any tools besides the
> compiler that may help you out?
>
> Job Honig
> TUD
>



--
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com

Ricky,

The sample Java code you present is horrible of course. That's not
what I meant by making a point of thinking about exceptions in my
code, to the contrary.

Do you want to say that I should go to a paradigm where exceptions
are replaced by sets of alternative outcomes (as Option does in a
very simple case)?

I'll give it some more thought, but actually that would not be any
different from having exceptions, would it? I could achieve the
same horror easily.

Job Honig

> I would suggest using exceptions for cases that you *aren't* going to
> programmatically handle, i.e., throw, but don't catch, and using
> Option/Either/whatever you like for other cases.
>
> Please note that this is my opinion (and that of some others), and not
> any "this is the Scala way". Checked exceptions via a plugin are
> planned, but currently unimplemented.
>
> If you're desperate, I expect it wouldn't be too difficult to write a
> bytecode analyser that looks for missing throws/catches, except in
> cases where type parameters are involved.
>
> Note that checked exceptions are quite a problem in most Java code. I
> estimate that 90% of all catch blocks I see in Java code are written
> badly (empty, swallow the exception just giving the message, log to
> debug level instead of warn/error, etc.). It's certainly not clear
> that checked exceptions, at least as Java does them, are a good thing.
>
> Here, have some Java:
>
> private byte[] blowfish( byte[] input, byte[] key )
> {
> byte[] initialisationVector = createInitialisationVector( nda );
>
> try
> {
> final Cipher cipher = Cipher.getInstance(
> "Blowfish/CFB/NoPadding" );
> cipher.init( Cipher.DECRYPT_MODE, new SecretKeySpec( key,
> "Blowfish" ), new IvParameterSpec( initialisationVector ) );
> return cipher.doFinal(input);
> }
> catch ( InvalidKeyException e )
> {
> throw new RuntimeException( e );
> }
> catch ( InvalidAlgorithmParameterException e )
> {
> throw new RuntimeException( e );
> }
> catch ( NoSuchAlgorithmException e )
> {
> throw new RuntimeException( e );
> }
> catch ( NoSuchPaddingException e )
> {
> throw new RuntimeException( e );
> }
> catch ( IllegalBlockSizeException ex )
> {
> throw new RuntimeException( ex );
> }
> catch ( BadPaddingException ex )
> {
> throw new RuntimeException( ex );
> }
> }
>
> 2009/9/3 Job Honig :
> > Hi All,
> >
> > I have a question about dealing with exceptions.   In my Java software,
> > exceptions have always played an important role in my architectures,
> > and I made a point of thinking where and how to handle them.
> >
> > Now I don't see how to accomplish this without a compiler that helps
> > me to track exceptions that might be thrown; to do that by hand is not
> > easy.  And I obviously don't want my exceptions to go unhandled and
> > have them thrown to the outside world.
> >
> > Can I do exactly the same as in Java with the @throws annotation?  I
> >
> > wonder...   At http://www.scala-lang.org/node/106 I read:
> >> Since Scala has no checked exceptions, Scala methods must be annotated
> >> with one or more throws annotations such that Java code can catch
> >> exceptions thrown by a Scala method.
> >
> > I can't do that properly, of course, because in order to do it I would
> > need the same kind of support as Java throws clauses  offered me in the
> > first place.
> >
> > Are the @throws clauses just an interface to Java, or are they really
> > the same as the Java throws?  And how do I know what @throws I
> > need if the compiler doesn't tell me in the first place?
> >
> > How do you guys solve this problem?  Are there any tools besides the
> > compiler that may help you out?
> >
> > Job Honig
> > TUD

The point of having Option[X] is to distinguish two use cases:

(1) Nothing is returned, and we expect this sometimes, and all we have to do is deal with it.
(2) Nothing is returned, and this is because something broke, and we need to know why, and we have to try to fix it.

Exceptions are used far too often for (1).  For example, if you're trying to parse text, and you expect a number, you rarely want to be so frantically alarmed that you stop the whole program.  Chances are you won't always get a number and you have to think about how to gracefully handle that every time.

Thus, integer parsing should return Option[Int].

But in Java they throw NumberFormatException, which means you have to wrap the whole thing in a catch block.

The key question to ask is, "Do I need to know *why* this failed as part of routine operations, or just *that* it failed?"  If knowing why is essential, or failure is exceedingly rare, you should probably be throwing an exception.  If knowing that it failed is enough, Option is a better choice.

Examples:
Out of disk space => User needs to know to fix => Code needs to know => exception
Couldn't find a key in a table => Who cares why => Option
Command line parameter not present => Can still run anyway => Option
Command line argument garbled => User needs to fix => exception (perhaps)
Can't download new web page because cache is full => Code needs to fix => exception
Get ping time to remote computer => Might time out => Option (perhaps)

  --Rex

On Thu, Sep 3, 2009 at 1:31 PM, Job Honig <joho@xs4all.nl> wrote:

Ricky,

The sample Java code you present is horrible of course.  That's not
what I meant by making a point of thinking about exceptions in my
code, to the contrary.

Do you want to say that I should go to a paradigm where exceptions
are replaced by sets of alternative outcomes (as Option does in a
very simple case)?

I'll give it some more thought, but actually that would not be any
different from having exceptions, would it?  I could achieve the
same horror easily.

Job Honig

> I would suggest using exceptions for cases that you *aren't* going to
> programmatically handle, i.e., throw, but don't catch, and using
> Option/Either/whatever you like for other cases.
>
> Please note that this is my opinion (and that of some others), and not
> any "this is the Scala way".  Checked exceptions via a plugin are
> planned, but currently unimplemented.
>
> If you're desperate, I expect it wouldn't be too difficult to write a
> bytecode analyser that looks for missing throws/catches, except in
> cases where type parameters are involved.
>
> Note that checked exceptions are quite a problem in most Java code.  I
> estimate that 90% of all catch blocks I see in Java code are written
> badly (empty, swallow the exception just giving the message, log to
> debug level instead of warn/error, etc.).  It's certainly not clear
> that checked exceptions, at least as Java does them, are a good thing.
>
> Here, have some Java:
>
>     private byte[] blowfish( byte[] input, byte[] key )
>     {
>         byte[] initialisationVector = createInitialisationVector( nda );
>
>         try
>         {
>             final Cipher cipher = Cipher.getInstance(
> "Blowfish/CFB/NoPadding" );
>             cipher.init( Cipher.DECRYPT_MODE, new SecretKeySpec( key,
> "Blowfish" ), new IvParameterSpec( initialisationVector ) );
>             return cipher.doFinal(input);
>         }
>         catch ( InvalidKeyException e )
>         {
>             throw new RuntimeException( e );
>         }
>         catch ( InvalidAlgorithmParameterException e )
>         {
>             throw new RuntimeException( e );
>         }
>         catch ( NoSuchAlgorithmException e )
>         {
>             throw new RuntimeException( e );
>         }
>         catch ( NoSuchPaddingException e )
>         {
>             throw new RuntimeException( e );
>         }
>         catch ( IllegalBlockSizeException ex )
>         {
>             throw new RuntimeException( ex );
>         }
>         catch ( BadPaddingException ex )
>         {
>             throw new RuntimeException( ex );
>         }
>     }
>
> 2009/9/3 Job Honig <joho@xs4all.nl>:
> > Hi All,
> >
> > I have a question about dealing with exceptions.   In my Java software,
> > exceptions have always played an important role in my architectures,
> > and I made a point of thinking where and how to handle them.
> >
> > Now I don't see how to accomplish this without a compiler that helps
> > me to track exceptions that might be thrown; to do that by hand is not
> > easy.  And I obviously don't want my exceptions to go unhandled and
> > have them thrown to the outside world.
> >
> > Can I do exactly the same as in Java with the @throws annotation?  I
> >
> > wonder...   At http://www.scala-lang.org/node/106 I read:
> >> Since Scala has no checked exceptions, Scala methods must be annotated
> >> with one or more throws annotations such that Java code can catch
> >> exceptions thrown by a Scala method.
> >
> > I can't do that properly, of course, because in order to do it I would
> > need the same kind of support as Java throws clauses  offered me in the
> > first place.
> >
> > Are the @throws clauses just an interface to Java, or are they really
> > the same as the Java throws?  And how do I know what @throws I
> > need if the compiler doesn't tell me in the first place?
> >
> > How do you guys solve this problem?  Are there any tools besides the
> > compiler that may help you out?
> >
> > Job Honig
> > TUD

Rex,

Thanks for your examples. The problems mainly arise in situations that
are far more complex than what you describe, where there are several
ways an operations could fail, and where each way should trigger a
specialized recovery process... Exceptions used to be the way to go,
but without compiler support that would be terribly difficult to manage
because you tend to overlook exceptions being thrown at you... I
can see how I could do that with a kind-of Option with more than 2
alternatives, but even then you don't get an awful lot of compiler
support and it wouldn't be any cleaner than handling exceptions in
the first place.

I'm rather new to Scala, so I have definitely to get accustomed to
the Scala way of doing things, but for now I don't see a lot of good
solutions for my problem. And of course I agree with those who say
there's a lot of horrible code involving exceptions... But they do have
their raison d'etre, IMHO, and deserve full language support. Making
them all unchecked doesn't feel like full support to me.

Job H.

> (1) Nothing is returned, and we expect this sometimes, and all we have to
> do is deal with it.
> (2) Nothing is returned, and this is because something broke, and we need
> to know why, and we have to try to fix it.
>
> Exceptions are used far too often for (1). For example, if you're trying
> to parse text, and you expect a number, you rarely want to be so
> frantically alarmed that you stop the whole program. Chances are you won't
> always get a number and you have to think about how to gracefully handle
> that every time.
>
> Thus, integer parsing should return Option[Int].
>
> But in Java they throw NumberFormatException, which means you have to wrap
> the whole thing in a catch block.
>
> The key question to ask is, "Do I need to know *why* this failed as part of
> routine operations, or just *that* it failed?" If knowing why is
> essential, or failure is exceedingly rare, you should probably be throwing
> an exception. If knowing that it failed is enough, Option is a better
> choice.
>
> Examples:
> Out of disk space => User needs to know to fix => Code needs to know =>
> exception
> Couldn't find a key in a table => Who cares why => Option
> Command line parameter not present => Can still run anyway => Option
> Command line argument garbled => User needs to fix => exception (perhaps)
> Can't download new web page because cache is full => Code needs to fix =>
> exception
> Get ping time to remote computer => Might time out => Option (perhaps)
>
> --Rex
>
> On Thu, Sep 3, 2009 at 1:31 PM, Job Honig wrote:
> > Ricky,
> >
> > The sample Java code you present is horrible of course. That's not
> > what I meant by making a point of thinking about exceptions in my
> > code, to the contrary.
> >
> > Do you want to say that I should go to a paradigm where exceptions
> > are replaced by sets of alternative outcomes (as Option does in a
> > very simple case)?
> >
> > I'll give it some more thought, but actually that would not be any
> > different from having exceptions, would it? I could achieve the
> > same horror easily.
> >
> > Job Honig
> >
> > > I would suggest using exceptions for cases that you *aren't* going to
> > > programmatically handle, i.e., throw, but don't catch, and using
> > > Option/Either/whatever you like for other cases.
> > >
> > > Please note that this is my opinion (and that of some others), and not
> > > any "this is the Scala way". Checked exceptions via a plugin are
> > > planned, but currently unimplemented.
> > >
> > > If you're desperate, I expect it wouldn't be too difficult to write a
> > > bytecode analyser that looks for missing throws/catches, except in
> > > cases where type parameters are involved.
> > >
> > > Note that checked exceptions are quite a problem in most Java code. I
> > > estimate that 90% of all catch blocks I see in Java code are written
> > > badly (empty, swallow the exception just giving the message, log to
> > > debug level instead of warn/error, etc.). It's certainly not clear
> > > that checked exceptions, at least as Java does them, are a good thing.
> > >
> > > Here, have some Java:
> > >
> > > private byte[] blowfish( byte[] input, byte[] key )
> > > {
> > > byte[] initialisationVector = createInitialisationVector( nda
> > > );
> > >
> > > try
> > > {
> > > final Cipher cipher = Cipher.getInstance(
> > > "Blowfish/CFB/NoPadding" );
> > > cipher.init( Cipher.DECRYPT_MODE, new SecretKeySpec( key,
> > > "Blowfish" ), new IvParameterSpec( initialisationVector ) );
> > > return cipher.doFinal(input);
> > > }
> > > catch ( InvalidKeyException e )
> > > {
> > > throw new RuntimeException( e );
> > > }
> > > catch ( InvalidAlgorithmParameterException e )
> > > {
> > > throw new RuntimeException( e );
> > > }
> > > catch ( NoSuchAlgorithmException e )
> > > {
> > > throw new RuntimeException( e );
> > > }
> > > catch ( NoSuchPaddingException e )
> > > {
> > > throw new RuntimeException( e );
> > > }
> > > catch ( IllegalBlockSizeException ex )
> > > {
> > > throw new RuntimeException( ex );
> > > }
> > > catch ( BadPaddingException ex )
> > > {
> > > throw new RuntimeException( ex );
> > > }
> > > }
> > >
> > > 2009/9/3 Job Honig :
> > > > Hi All,
> > > >
> > > > I have a question about dealing with exceptions. In my Java
> > > > software, exceptions have always played an important role in my
> > > > architectures, and I made a point of thinking where and how to handle
> > > > them.
> > > >
> > > > Now I don't see how to accomplish this without a compiler that helps
> > > > me to track exceptions that might be thrown; to do that by hand is
> > > > not easy. And I obviously don't want my exceptions to go unhandled
> > > > and have them thrown to the outside world.
> > > >
> > > > Can I do exactly the same as in Java with the @throws annotation? I
> > > >
> > > > wonder... At http://www.scala-lang.org/node/106 I read:
> > > >> Since Scala has no checked exceptions, Scala methods must be
> > > >> annotated with one or more throws annotations such that Java code
> > > >> can catch exceptions thrown by a Scala method.
> > > >
> > > > I can't do that properly, of course, because in order to do it I
> > > > would need the same kind of support as Java throws clauses offered
> > > > me in the first place.
> > > >
> > > > Are the @throws clauses just an interface to Java, or are they really
> > > > the same as the Java throws? And how do I know what @throws I
> > > > need if the compiler doesn't tell me in the first place?
> > > >
> > > > How do you guys solve this problem? Are there any tools besides the
> > > > compiler that may help you out?
> > > >
> > > > Job Honig
> > > > TUD

And if there's more than one option, you would write

Either (Err1, Either (Err2, Either (Err3, Result)?

Why is that a cleaner solution than checked exceptions?

> On Thursday September 3 2009, Rex Kerr wrote:
> > The point of having Option[X] is to distinguish two use cases:
> >
> > (1) Nothing is returned, and we expect this sometimes, and all we
> > have to do is deal with it.
> > (2) Nothing is returned, and this is because something broke, and we
> > need to know why, and we have to try to fix it.
> >
> > Exceptions are used far too often for (1). ...
> >
> > The key question to ask is, "Do I need to know *why* this failed as
> > part of routine operations, or just *that* it failed?" If knowing
> > why is essential, or failure is exceedingly rare, you should probably
> > be throwing an exception. If knowing that it failed is enough,
> > Option is a better choice.
>
> I don't think even category (2) justifies much use of exceptions in
> Scala code. I recently "discovered" Either, the neglected cousin by
> comparison with the much-discussed Option. Check it out.
>
> Now that I know about it, all my high-level, error-accommodating APIs
> return Either[ERec, SomethingUseful]. ERec is one of my own utility
> classes for error handling. For what it's worth, ERec encapsulates a
> Throwable instance along with an error message, a severity code, and
> location information, most of which are optional, so for cases where
> the error originates in an caught exception, it can be preserved along
> with the rest of the characterizations of the error condition that was
> detected.
>
> > ...
> >
> > --Rex
>
> Randall Schulz

On Thursday September 3 2009, Rex Kerr wrote:
> The point of having Option[X] is to distinguish two use cases:
>
> (1) Nothing is returned, and we expect this sometimes, and all we
> have to do is deal with it.
> (2) Nothing is returned, and this is because something broke, and we
> need to know why, and we have to try to fix it.
>
> Exceptions are used far too often for (1). ...
>
> The key question to ask is, "Do I need to know *why* this failed as
> part of routine operations, or just *that* it failed?" If knowing
> why is essential, or failure is exceedingly rare, you should probably
> be throwing an exception. If knowing that it failed is enough,
> Option is a better choice.

I don't think even category (2) justifies much use of exceptions in
Scala code. I recently "discovered" Either, the neglected cousin by
comparison with the much-discussed Option. Check it out.

Now that I know about it, all my high-level, error-accommodating APIs
return Either[ERec, SomethingUseful]. ERec is one of my own utility
classes for error handling. For what it's worth, ERec encapsulates a
Throwable instance along with an error message, a severity code, and
location information, most of which are optional, so for cases where
the error originates in an caught exception, it can be preserved along
with the rest of the characterizations of the error condition that was
detected.

> ...
>
> --Rex

Randall Schulz

On Thu, Sep 03, 2009 at 02:02:48PM -0400, Rex Kerr wrote:
> The key question to ask is, "Do I need to know *why* this failed as
> part of routine operations, or just *that* it failed?" If knowing why
> is essential, or failure is exceedingly rare, you should probably be
> throwing an exception. If knowing that it failed is enough, Option is
> a better choice.

Either is underused here. Anything that can be dealt with by throwing
exceptions can also be dealt with by returning Either[Throwable,T], and
if you really think all callers need to deal with that failure, then
this makes a lot more sense in scala.

BTW I'll just advertise the availability of this again. You can compose
Catch objects and get all kinds of error handling in place which you can
then reuse in different circumstances. It can still be improved but
that would be more likely to happen if I heard about someone using it...

scala> import scala.util.control.Exception._
import scala.util.control.Exception._

scala> catching(classOf[NumberFormatException]) either "123".toInt
res0: Either[Throwable,Int] = Right(123)

scala> catching(classOf[NumberFormatException]) either "123boogle".toInt
res1: Either[Throwable,Int] = Left(java.lang.NumberFormatException: For input string: "123boogle")

scala> catching(classOf[NumberFormatException]) opt "456".toInt
res2: Option[Int] = Some(456)

scala> catching(classOf[NumberFormatException]) opt "456bargle".toInt
res3: Option[Int] = None

On Thursday September 3 2009, Job Honig wrote:
> And if there's more than one option, you would write
>
> Either (Err1, Either (Err2, Either (Err3, Result)?
>
> Why is that a cleaner solution than checked exceptions?

It's not. Don't use it that way. We have other abstraction mechanisms
that compose with type constructors such as Either and they easily
accommodate this sort of thing.

Randall Schulz

 Checked exceptions were an attempt at allowing a greater level of
static validation, you tell the compiler that a method can throw an exception
of type X, and it will force any caller of a method to deal with it.

 The problem is that most of the time the immediate calling code
can not resolve exceptions, they will pass it to their caller and so forth
until, lower on the call stack, a decision can be taken, which is just
what unchecked exceptions do, so In the example given by Ricky,
the API designer is to blame (in my opinion).
The scala Option is another attempt at telling the compiler about what
can or cannot be null, to allow it to do greater static validation on
nullilty related errors.

In my opinion Options and checked exception are only related in this way :
They are declarations to the compiler to help it do static validation,
checked exceptions were a failed attempt, (not convinced if the concept
is inherently flawed, but certainly misused 95% of the time), time will tell
if Option will succed (in being a usefull validation mechanism).
So far I have no opinion on Option because I haven't written much Scala.

That was my 0.02$ !


On Thu, Sep 3, 2009 at 1:31 PM, Job Honig <joho@xs4all.nl> wrote:

Ricky,

The sample Java code you present is horrible of course.  That's not
what I meant by making a point of thinking about exceptions in my
code, to the contrary.

Do you want to say that I should go to a paradigm where exceptions
are replaced by sets of alternative outcomes (as Option does in a
very simple case)?

I'll give it some more thought, but actually that would not be any
different from having exceptions, would it?  I could achieve the
same horror easily.

Job Honig

> I would suggest using exceptions for cases that you *aren't* going to
> programmatically handle, i.e., throw, but don't catch, and using
> Option/Either/whatever you like for other cases.
>
> Please note that this is my opinion (and that of some others), and not
> any "this is the Scala way".  Checked exceptions via a plugin are
> planned, but currently unimplemented.
>
> If you're desperate, I expect it wouldn't be too difficult to write a
> bytecode analyser that looks for missing throws/catches, except in
> cases where type parameters are involved.
>
> Note that checked exceptions are quite a problem in most Java code.  I
> estimate that 90% of all catch blocks I see in Java code are written
> badly (empty, swallow the exception just giving the message, log to
> debug level instead of warn/error, etc.).  It's certainly not clear
> that checked exceptions, at least as Java does them, are a good thing.
>
> Here, have some Java:
>
>     private byte[] blowfish( byte[] input, byte[] key )
>     {
>         byte[] initialisationVector = createInitialisationVector( nda );
>
>         try
>         {
>             final Cipher cipher = Cipher.getInstance(
> "Blowfish/CFB/NoPadding" );
>             cipher.init( Cipher.DECRYPT_MODE, new SecretKeySpec( key,
> "Blowfish" ), new IvParameterSpec( initialisationVector ) );
>             return cipher.doFinal(input);
>         }
>         catch ( InvalidKeyException e )
>         {
>             throw new RuntimeException( e );
>         }
>         catch ( InvalidAlgorithmParameterException e )
>         {
>             throw new RuntimeException( e );
>         }
>         catch ( NoSuchAlgorithmException e )
>         {
>             throw new RuntimeException( e );
>         }
>         catch ( NoSuchPaddingException e )
>         {
>             throw new RuntimeException( e );
>         }
>         catch ( IllegalBlockSizeException ex )
>         {
>             throw new RuntimeException( ex );
>         }
>         catch ( BadPaddingException ex )
>         {
>             throw new RuntimeException( ex );
>         }
>     }
>
> 2009/9/3 Job Honig <joho@xs4all.nl>:
> > Hi All,
> >
> > I have a question about dealing with exceptions.   In my Java software,
> > exceptions have always played an important role in my architectures,
> > and I made a point of thinking where and how to handle them.
> >
> > Now I don't see how to accomplish this without a compiler that helps
> > me to track exceptions that might be thrown; to do that by hand is not
> > easy.  And I obviously don't want my exceptions to go unhandled and
> > have them thrown to the outside world.
> >
> > Can I do exactly the same as in Java with the @throws annotation?  I
> >
> > wonder...   At http://www.scala-lang.org/node/106 I read:
> >> Since Scala has no checked exceptions, Scala methods must be annotated
> >> with one or more throws annotations such that Java code can catch
> >> exceptions thrown by a Scala method.
> >
> > I can't do that properly, of course, because in order to do it I would
> > need the same kind of support as Java throws clauses  offered me in the
> > first place.
> >
> > Are the @throws clauses just an interface to Java, or are they really
> > the same as the Java throws?  And how do I know what @throws I
> > need if the compiler doesn't tell me in the first place?
> >
> > How do you guys solve this problem?  Are there any tools besides the
> > compiler that may help you out?
> >
> > Job Honig
> > TUD

On Thursday 03 September 2009 08:31:08 pm Randall R Schulz wrote:
> On Thursday September 3 2009, Job Honig wrote:
> > And if there's more than one option, you would write
> >
> > Either (Err1, Either (Err2, Either (Err3, Result)?
> >
> > Why is that a cleaner solution than checked exceptions?
>
> It's not. Don't use it that way. We have other abstraction mechanisms
> that compose with type constructors such as Either and they easily
> accommodate this sort of thing.

Yes, I already suggested something like Option (or either) but with multiple
options. I will try to do something along those lines. My point was that it
wouldn't be a lot cleaner than exceptions, and that exceptions are still
part of the language but in my view rather useless because they are not
checked.

Job

OK, I start to see what you all mean. I'll try to apply it and then come
back with praise or complaints :-)

> On Thu, Sep 03, 2009 at 02:02:48PM -0400, Rex Kerr wrote:
> > The key question to ask is, "Do I need to know *why* this failed as
> > part of routine operations, or just *that* it failed?" If knowing why
> > is essential, or failure is exceedingly rare, you should probably be
> > throwing an exception. If knowing that it failed is enough, Option is
> > a better choice.
>
> Either is underused here. Anything that can be dealt with by throwing
> exceptions can also be dealt with by returning Either[Throwable,T], and
> if you really think all callers need to deal with that failure, then
> this makes a lot more sense in scala.
>
> BTW I'll just advertise the availability of this again. You can compose
> Catch objects and get all kinds of error handling in place which you can
> then reuse in different circumstances. It can still be improved but
> that would be more likely to happen if I heard about someone using it...
>
> scala> import scala.util.control.Exception._
> import scala.util.control.Exception._
>
> scala> catching(classOf[NumberFormatException]) either "123".toInt
> res0: Either[Throwable,Int] = Right(123)
>
> scala> catching(classOf[NumberFormatException]) either "123boogle".toInt
> res1: Either[Throwable,Int] = Left(java.lang.NumberFormatException: For
> input string: "123boogle")
>
> scala> catching(classOf[NumberFormatException]) opt "456".toInt
> res2: Option[Int] = Some(456)
>
> scala> catching(classOf[NumberFormatException]) opt "456bargle".toInt
> res3: Option[Int] = None

On Thu, Sep 3, 2009 at 2:19 PM, Randall R Schulz <rschulz@sonic.net> wrote:

On Thursday September 3 2009, Rex Kerr wrote:
> The point of having Option[X] is to distinguish two use cases:
>
> (1) Nothing is returned, and we expect this sometimes, and all we
> have to do is deal with it.
> (2) Nothing is returned, and this is because something broke, and we
> need to know why, and we have to try to fix it.
>
> Exceptions are used far too often for (1).  ...
>

I don't think even category (2) justifies much use of exceptions in
Scala code. I recently "discovered" Either, the neglected cousin by
comparison with the much-discussed Option. Check it out.

I do know about Either, but I have yet to come up with a compelling reason why it's superior to throw/catch.  There's been a lot of work on throw/catch performance, so if the error condition is somewhat rare, throw/catch should perform better.  You don't, in Scala, have to declare your exceptions, so the compiler fails to help you out like it would with Either, but I don't view that as a compelling reason to change use patterns--just a potential compiler weakness.  Try/catch lets you descend multiple levels without having to explicitly repeat your code dealing with special cases.  Try/catch, while syntactically ugly, is more compact than match, and is more clearly related to an error condition than "isLeft" or "isRight".  Either *does* give you the option of deferring error-handling for arbitrarily long, and it certainly encapsulates the idea of returns that can take on multiple types, so there are cases where I would use it without hesitation.

Either is, however, a decent substitute for try/catch, as long as the error chain is not too long.  I don't see any particular harm in using it; I just haven't yet seen use cases where it's a significant benefit over Java-style exceptions.

  --Rex

> Either is, however, a decent substitute for try/catch, as long as the error
> chain is not too long. I don't see any particular harm in using it; I just
> haven't yet seen use cases where it's a significant benefit over Java-style
> exceptions.

Agreed.

What were the reasons to exceptions at all, in Scala? The value-approach
could have been taken all the way, couldn't it? Instead of almost using them
as a kind of exit (1) :-)

Job

On Thu, Sep 03, 2009 at 02:35:52PM -0400, Maxime Lévesque wrote:
> The scala Option is another attempt at telling the compiler about what
> can or cannot be null, to allow it to do greater static validation on
> nullilty related errors.

This is misleading at best, because Option does not at all protect you
from null, and in fact complicates the situation:

scala> def strlen(x: Option[String]) = x.getOrElse("abc").length
strlen: (x: Option[String])Int

scala> strlen(Some(null))
java.lang.NullPointerException

scala> strlen(null)
java.lang.NullPointerException

Now if you are dealing with data which might be null, instead of having
to check whether it is or isn't null (2 cases) you have FOUR cases to
deal with: the Option[T] may be null, None, Some(null) or Some(x: T).

Option is a generic mechanism for transmitting one out-of-band bit about
a value. That bit may be used to transmit a piece of information which
in java would usually be transmitted by null, and in that sense Option
is related to null. But it does not inherently solve any problems
related to null checking, except inasmuch as it discourages you from
introducing even more nulls into your poor defenseless code.

p, li { white-space: pre-wrap; }

I think that the general idea is that you're *supposed* to throw NPE's when someone tries to call a method with nulls when nulls aren't accepted. It's the user's fault that a null was sent, and a method shouldn't silently treat null like a None when the two aren't the same, IMO. This only leads to debugging hells after a while.

On Thursday 03 September 2009 20:59:05 Paul Phillips wrote:

> On Thu, Sep 03, 2009 at 02:35:52PM -0400, Maxime Lévesque wrote:

> > The scala Option is another attempt at telling the compiler about what

> > can or cannot be null, to allow it to do greater static validation on

> > nullilty related errors.

>

> This is misleading at best, because Option does not at all protect you

> from null, and in fact complicates the situation:

>

> scala> def strlen(x: Option[String]) = x.getOrElse("abc").length

> strlen: (x: Option[String])Int

>

> scala> strlen(Some(null))

> java.lang.NullPointerException

>

> scala> strlen(null)

> java.lang.NullPointerException

>

> Now if you are dealing with data which might be null, instead of having

> to check whether it is or isn't null (2 cases) you have FOUR cases to

> deal with: the Option[T] may be null, None, Some(null) or Some(x: T).

>

> Option is a generic mechanism for transmitting one out-of-band bit about

> a value. That bit may be used to transmit a piece of information which

> in java would usually be transmitted by null, and in that sense Option

> is related to null. But it does not inherently solve any problems

> related to null checking, except inasmuch as it discourages you from

> introducing even more nulls into your poor defenseless code.

>

David Flemström

david.flemstrom@gmail.com

Paul Phillips wrote:
> (...)
> Option is a generic mechanism for transmitting one out-of-band bit about
> a value. That bit may be used to transmit a piece of information which
> in java would usually be transmitted by null, and in that sense Option
> is related to null. But it does not inherently solve any problems
> related to null checking, except inasmuch as it discourages you from
> introducing even more nulls into your poor defenseless code.

And again, a pity that implicit null-to-X conversions don't generally work.

-Martin

On Thu, Sep 03, 2009 at 09:37:30PM +0200, David Flemström wrote:
> It's the user's fault that a null was sent, and a method shouldn't
> silently treat null like a None when the two aren't the same, IMO.
> This only leads to debugging hells after a while.

I was surely not suggesting that the compiler treat them as the same. I
was pointing out that the statement:

"The scala Option is another attempt at telling the compiler about what
can or cannot be null, to allow it to do greater static validation on
nullilty related errors."

...is not true, because the scala compiler does not pay any regard to
whether something can or can't be null, and does no additional static
validation on nullity related errors. (There is some code that does try
for that, but a) it doesn't have the necessary degree of sophistication
to address this problem and b) it's not related to Option.)

scala> var x: String with NotNull = "abc"
x: String with NotNull = abc

scala> x = null
:5: error: type mismatch;
found : Null(null)
required: String with NotNull
x = null
^

p, li { white-space: pre-wrap; }

I'm sorry, I didn't make myself clear. I mean that it shouldn't be the job of a method with 'Option'al parameters to check if the arguments are null or not; if the method gets a null, it should fail with an NPE. That would be what I would expect, and I would start looking for errors elsewhere if a method didn't behave like that.

On Thursday 03 September 2009 22:08:52 Paul Phillips wrote:

> On Thu, Sep 03, 2009 at 09:37:30PM +0200, David Flemström wrote:

> > It's the user's fault that a null was sent, and a method shouldn't

> > silently treat null like a None when the two aren't the same, IMO.

> > This only leads to debugging hells after a while.

>

> I was surely not suggesting that the compiler treat them as the same. I

> was pointing out that the statement:

>

> "The scala Option is another attempt at telling the compiler about what

> can or cannot be null, to allow it to do greater static validation on

> nullilty related errors."

>

> ...is not true, because the scala compiler does not pay any regard to

> whether something can or can't be null, and does no additional static

> validation on nullity related errors. (There is some code that does try

> for that, but a) it doesn't have the necessary degree of sophistication

> to address this problem and b) it's not related to Option.)

>

> scala> var x: String with NotNull = "abc"

> x: String with NotNull = abc

>

> scala> x = null

> <console>:5: error: type mismatch;

> found : Null(null)

> required: String with NotNull

> x = null

> ^

>

David Flemström

david.flemstrom@gmail.com

On Thu, Sep 03, 2009 at 10:25:28PM +0200, David Flemström wrote:
> I'm sorry, I didn't make myself clear. I mean that it shouldn't be the
> job of a method with 'Option'al parameters to check if the arguments
> are null or not; if the method gets a null, it should fail with an
> NPE. That would be what I would expect, and I would start looking for
> errors elsewhere if a method didn't behave like that.

I do not find this an entirely accurate representation either, because
Option is used in the core scala API and elsewhere for other purposes,
it is not merely a null wrapper. You are implying that by receiving
Option you are expressing something specific about nullity, and shifting
the responsibility to the caller. But Option can mean anything, like it
does here:

// let's find the first String in the list that's not "def"
scala> List (null, "abc", "abc", "def") find (_ != "def")
res0: Option[java.lang.String] = Some(null)

My point is that Option does not present any meaningful barrier to NPEs,
except to the extent that you use it in preference to nulls - but that
is only a convention, the compiler is not assisting you. And you are
still dependent on the same highly fallible humans-getting-it-right
factors as you are with if (x != null) ...

It has more than once occurred to me that at least the purposes
"optional value" and "not-null designator" should be represented in some
distinguishable fashion, but that ship has probably sailed for now.

On Thursday 03 September 2009 22:46:09 Paul Phillips wrote:
> I do not find this an entirely accurate representation either, because
> Option is used in the core scala API and elsewhere for other purposes,
> it is not merely a null wrapper.
I agree with you completely. But I still think that you are missing my point.
As far as I am aware, there are two approaches to handling null parameters:

1. You treat null arguments as if the argument in question was missing (as if
the argument had been 'Option'al), and try to load various default values and
work around the fact that you're lacking information from the user.
E.g:
def something(b: Object) = {
val x = if(b == null) new Something else b
performCalculation(x)
}

2. You tell the user of your method directly that a parameter is null that's
not supposed to be null, and lets him/her fix it on his/her side.
E.g:
def soemthing(b: Object) = performCalculation(b)

The only thing that I'm saying is that if you take path #2, Option would be a
good way to tell your user that he/she indeed *would* be able to omit a
parameter, and thus there wouldn't be a need for the user to ever submit a
null parameter explicitly to a method.

Of course, Option has a lot of other uses too, and there might even be a valid
use for null, but that's beside the point.

Also, I'm not trying to reduce the number of NPEs in the world or anything,
I'm just saying that using Options wverywhere where a parameter is optional
would give the user a chance to see where previosuly null would have been
passed *before* hitting the compile&run button, and that it therefore is a
great tool that should be used *instead* of having nullable parameters that
are explained in Scaladocs how to use, even if the effect just is aesthetic.

David Flemström
david.flemstrom@gmail.com

Paul Phillips wrote on 03/09/2009 19:22:18:
> Either is underused here. Anything that can be dealt with by throwing
> exceptions can also be dealt with by returning Either[Throwable,T], and
> if you really think all callers need to deal with that failure, then
> this makes a lot more sense in scala.
>
> ...

This post just gave me one of those lovely "aha! I get it!" moments, so
thanks for that.

I do have one question, could using Either mean that it is more awkward to
produce an exception chain? So, at some point of actually handling the
problem, you would normally just end up with having the root cause that
was put in the left? I just wondered, though I have to say that I do not
commonly find anything other than the root cause to be particularly useful
in tracking down a problem. Even so, I'd be interested if there is a
common idiom for easily simulating that type of usage...

Kieron

This message may contain confidential and privileged information and is intended solely for the use of the named addressee. Access, copying or re-use of the e-mail or any information contained therein by any other person is not authorised. If you are not the intended recipient please notify us immediately by returning the e-mail to the originator and then immediately delete this message. Although we attempt to sweep e-mail and attachments for viruses, we do not guarantee that either are virus-free and accept no liability for any damage sustained as a result of viruses.

Please refer to http://www.bnymellon.com/disclaimer/piml.html for certain disclosures.

On Fri, Sep 04, 2009 at 11:04:32AM +0100, Kieron.Wilkinson@paretopartners.com wrote:
> I do have one question, could using Either mean that it is more
> awkward to produce an exception chain? So, at some point of actually
> handling the problem, you would normally just end up with having the
> root cause that was put in the left?

It's a good question. People bring it up often enough that I wonder if
the generic structure ought to be Either[List[Throwable], T], or more
likely if I should create a container class with a chained variant that
kicks in if the oops box is already full.

On Thu, Sep 03, 2009 at 03:36:52PM -0400, Martin S. Weber wrote:
> And again, a pity that implicit null-to-X conversions don't generally
> work.

It is. That gave me an idea though. (One of) the problems with
conversions from null is that implicits only take places if the usage
doesn't type check, and null type checks with everything but values.
(Another is that the compiler refuses to use otherwise eligible
implicits on literal null sometimes for reasons I don't remember, and
that I can't seem to work around.)

scala> implicit def x2y[T](x: T): Option[T] = if (x == null) None else Some(x)
x2y: [T](x: T)Option[T]

scala> val x: Option[String] = (null: String)
x: Option[String] = None

// oops
scala> val x: Option[String] = null
x: Option[String] = null

What if Option was not nullable? Unfortunately Option is final so we
can't go mixing in the traits we fancy, so we have to recreate it.

object paulp {
sealed abstract class OptionNoNull[+T] extends NotNull
case class Some[+T](x: T) extends OptionNoNull[T]
case object None extends OptionNoNull[Nothing]

implicit def wrapper[T](x: T) = if (x == null) None else Some(x)
}

scala> import paulp._
import paulp._

scala> val x: OptionNoNull[String] = (null: String)
x: paulp.OptionNoNull[String] = None

// a ha
scala> val x: OptionNoNull[String] = null
x: paulp.OptionNoNull[String] = None

Then remembering there are two problems to solve here (both an Option
which is null and a value which is null) I started expanding this out
like so, because a type parameter bound like T <: NotNull makes it
pretty much unusable.

sealed abstract class OptionNoNull[+T] extends NotNull {
def get: T // with compiler help could be T with NotNull
def isEmpty: Boolean
}
case class PSome[+T](x: T) extends OptionNoNull[T] {
def get: T = if (x == null) PNone.get else x
def isEmpty: Boolean = x != null
}
case object PNone extends OptionNoNull[Nothing] {
def get = throw new NoSuchElementException("None.get")
def isEmpty: Boolean = true
}

And THEN I started wasting all kinds of time on nutty implicit
approaches and conversions from scala.Option to paulp.Option and
manifests showing T <:< NotNull and said whoa man, time to regroup.

What I really need is a compiler-aware method for "null cleaning" any
value. You pass it a T and it passes back Option[T with NotNull] or
something similar.

Not sure if this is only in 2.8, but in the Option object we have:
def apply[A](x: A): Option[A] = if (x == null) None else Some(x)
Which means you can write:
val safeVal = Option(nullableVal)
Of course, if nullableVal is itself an Option, then we could end up with an instance of Option[Option[T]], which is less than ideal.
I'm wondering if Option.apply() should maybe check if the supplied argument is already an Option, then return it unchanged if so.


On Fri, Sep 4, 2009 at 4:11 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Sep 03, 2009 at 03:36:52PM -0400, Martin S. Weber wrote:
> And again, a pity that implicit null-to-X conversions don't generally
> work.

It is.  That gave me an idea though.  (One of) the problems with
conversions from null is that implicits only take places if the usage
doesn't type check, and null type checks with everything but values.
(Another is that the compiler refuses to use otherwise eligible
implicits on literal null sometimes for reasons I don't remember, and
that I can't seem to work around.)

scala> implicit def x2y[T](x: T): Option[T] = if (x == null) None else Some(x)
x2y: [T](x: T)Option[T]

scala> val x: Option[String] = (null: String)
x: Option[String] = None

// oops
scala> val x: Option[String] = null
x: Option[String] = null

What if Option was not nullable? Unfortunately Option is final so we
can't go mixing in the traits we fancy, so we have to recreate it.

object paulp {
 sealed abstract class OptionNoNull[+T] extends NotNull
 case class Some[+T](x: T) extends OptionNoNull[T]
 case object None extends OptionNoNull[Nothing]

 implicit def wrapper[T](x: T) = if (x == null) None else Some(x)
}

scala> import paulp._
import paulp._

scala> val x: OptionNoNull[String] = (null: String)
x: paulp.OptionNoNull[String] = None

// a ha
scala> val x: OptionNoNull[String] = null
x: paulp.OptionNoNull[String] = None


Then remembering there are two problems to solve here (both an Option
which is null and a value which is null) I started expanding this out
like so, because a type parameter bound like T <: NotNull makes it
pretty much unusable.

 sealed abstract class OptionNoNull[+T] extends NotNull {
   def get: T  // with compiler help could be T with NotNull
   def isEmpty: Boolean
 }
 case class PSome[+T](x: T) extends OptionNoNull[T] {
   def get: T = if (x == null) PNone.get else x
   def isEmpty: Boolean = x != null
 }
 case object PNone extends OptionNoNull[Nothing] {
   def get = throw new NoSuchElementException("None.get")
   def isEmpty: Boolean = true
 }

And THEN I started wasting all kinds of time on nutty implicit
approaches and conversions from scala.Option to paulp.Option and
manifests showing T <:< NotNull and said whoa man, time to regroup.

What I really need is a compiler-aware method for "null cleaning" any
value.  You pass it a T and it passes back Option[T with NotNull] or
something similar.

--
Paul Phillips      | A national political campaign is better than the
Everyman           | best circus ever heard of, with a mass baptism and
Empiricist         | a couple of hangings thrown in.
pull his pi pal!   |     -- H. L. Mencken

It shouldn't, because that wouldn't type-check.

Option.apply(Some(3)) would need to return an Option[Option[Int]], not
an Option[Int].

2009/9/4 Kevin Wright :
> Not sure if this is only in 2.8, but in the Option object we have:
> def apply[A](x: A): Option[A] = if (x == null) None else Some(x)
> Which means you can write:
> val safeVal = Option(nullableVal)
> Of course, if nullableVal is itself an Option, then we could end up with an
> instance of Option[Option[T]], which is less than ideal.
> I'm wondering if Option.apply() should maybe check if the supplied argument
> is already an Option, then return it unchanged if so.
>
>
> On Fri, Sep 4, 2009 at 4:11 PM, Paul Phillips wrote:
>>
>> On Thu, Sep 03, 2009 at 03:36:52PM -0400, Martin S. Weber wrote:
>> > And again, a pity that implicit null-to-X conversions don't generally
>> > work.
>>
>> It is.  That gave me an idea though.  (One of) the problems with
>> conversions from null is that implicits only take places if the usage
>> doesn't type check, and null type checks with everything but values.
>> (Another is that the compiler refuses to use otherwise eligible
>> implicits on literal null sometimes for reasons I don't remember, and
>> that I can't seem to work around.)
>>
>> scala> implicit def x2y[T](x: T): Option[T] = if (x == null) None else
>> Some(x)
>> x2y: [T](x: T)Option[T]
>>
>> scala> val x: Option[String] = (null: String)
>> x: Option[String] = None
>>
>> // oops
>> scala> val x: Option[String] = null
>> x: Option[String] = null
>>
>> What if Option was not nullable? Unfortunately Option is final so we
>> can't go mixing in the traits we fancy, so we have to recreate it.
>>
>> object paulp {
>>  sealed abstract class OptionNoNull[+T] extends NotNull
>>  case class Some[+T](x: T) extends OptionNoNull[T]
>>  case object None extends OptionNoNull[Nothing]
>>
>>  implicit def wrapper[T](x: T) = if (x == null) None else Some(x)
>> }
>>
>> scala> import paulp._
>> import paulp._
>>
>> scala> val x: OptionNoNull[String] = (null: String)
>> x: paulp.OptionNoNull[String] = None
>>
>> // a ha
>> scala> val x: OptionNoNull[String] = null
>> x: paulp.OptionNoNull[String] = None
>>
>>
>> Then remembering there are two problems to solve here (both an Option
>> which is null and a value which is null) I started expanding this out
>> like so, because a type parameter bound like T <: NotNull makes it
>> pretty much unusable.
>>
>>  sealed abstract class OptionNoNull[+T] extends NotNull {
>>    def get: T  // with compiler help could be T with NotNull
>>    def isEmpty: Boolean
>>  }
>>  case class PSome[+T](x: T) extends OptionNoNull[T] {
>>    def get: T = if (x == null) PNone.get else x
>>    def isEmpty: Boolean = x != null
>>  }
>>  case object PNone extends OptionNoNull[Nothing] {
>>    def get = throw new NoSuchElementException("None.get")
>>    def isEmpty: Boolean = true
>>  }
>>
>> And THEN I started wasting all kinds of time on nutty implicit
>> approaches and conversions from scala.Option to paulp.Option and
>> manifests showing T <:< NotNull and said whoa man, time to regroup.
>>
>> What I really need is a compiler-aware method for "null cleaning" any
>> value.  You pass it a T and it passes back Option[T with NotNull] or
>> something similar.
>>
>> --
>> Paul Phillips      | A national political campaign is better than the
>> Everyman           | best circus ever heard of, with a mass baptism and
>> Empiricist         | a couple of hangings thrown in.
>> pull his pi pal!   |     -- H. L. Mencken
>
>

How about this?
def apply[A](x: A): Option[A] = {  x match {    case Option[_] => x    case _ => if (x == null) None else Some(x)  }}

On Fri, Sep 4, 2009 at 4:20 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Sep 04, 2009 at 04:19:07PM +0100, Kevin Wright wrote:
> I'm wondering if Option.apply() should maybe check if the supplied
> argument is already an Option, then return it unchanged if so.

And what would the type signature of that method be? (Try to write it.)

--
Paul Phillips      | All men are frauds.  The only difference between
Apatheist          | them is that some admit it.  I myself deny it.
Empiricist         |     -- H. L. Mencken
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

I guess this whole escapade boils down to the fact it would be nice to have the compiler enforce things like this:

def foo[T](t :T ) : Option[T with NotNull] = if (t == null) None else Some(t)

On Fri, Sep 4, 2009 at 5:11 PM, Paul Phillips <paulp@improving.org> wrote:

On Thu, Sep 03, 2009 at 03:36:52PM -0400, Martin S. Weber wrote:
> And again, a pity that implicit null-to-X conversions don't generally
> work.

It is.  That gave me an idea though.  (One of) the problems with
conversions from null is that implicits only take places if the usage
doesn't type check, and null type checks with everything but values.
(Another is that the compiler refuses to use otherwise eligible
implicits on literal null sometimes for reasons I don't remember, and
that I can't seem to work around.)

scala> implicit def x2y[T](x: T): Option[T] = if (x == null) None else Some(x)
x2y: [T](x: T)Option[T]

scala> val x: Option[String] = (null: String)
x: Option[String] = None

// oops
scala> val x: Option[String] = null
x: Option[String] = null

What if Option was not nullable? Unfortunately Option is final so we
can't go mixing in the traits we fancy, so we have to recreate it.

object paulp {
 sealed abstract class OptionNoNull[+T] extends NotNull
 case class Some[+T](x: T) extends OptionNoNull[T]
 case object None extends OptionNoNull[Nothing]

 implicit def wrapper[T](x: T) = if (x == null) None else Some(x)
}

scala> import paulp._
import paulp._

scala> val x: OptionNoNull[String] = (null: String)
x: paulp.OptionNoNull[String] = None

// a ha
scala> val x: OptionNoNull[String] = null
x: paulp.OptionNoNull[String] = None


Then remembering there are two problems to solve here (both an Option
which is null and a value which is null) I started expanding this out
like so, because a type parameter bound like T <: NotNull makes it
pretty much unusable.

 sealed abstract class OptionNoNull[+T] extends NotNull {
   def get: T  // with compiler help could be T with NotNull
   def isEmpty: Boolean
 }
 case class PSome[+T](x: T) extends OptionNoNull[T] {
   def get: T = if (x == null) PNone.get else x
   def isEmpty: Boolean = x != null
 }
 case object PNone extends OptionNoNull[Nothing] {
   def get = throw new NoSuchElementException("None.get")
   def isEmpty: Boolean = true
 }

And THEN I started wasting all kinds of time on nutty implicit
approaches and conversions from scala.Option to paulp.Option and
manifests showing T <:< NotNull and said whoa man, time to regroup.

What I really need is a compiler-aware method for "null cleaning" any
value.  You pass it a T and it passes back Option[T with NotNull] or
something similar.

--
Paul Phillips      | A national political campaign is better than the
Everyman           | best circus ever heard of, with a mass baptism and
Empiricist         | a couple of hangings thrown in.
pull his pi pal!   |     -- H. L. Mencken

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

On Fri, Sep 4, 2009 at 5:20 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Sep 04, 2009 at 04:19:07PM +0100, Kevin Wright wrote:
> I'm wondering if Option.apply() should maybe check if the supplied
> argument is already an Option, then return it unchanged if so.

And what would the type signature of that method be? (Try to write it.)

scala> object foo {
     | def apply[T](t : T) : Option[T] = if (t == null) None else Some(t)
     | def apply[T](t : Option[T]) : Option[T] = t
     | }
defined module foo

scala> foo(Some(10))
res0: Option[Int] = Some(10)

scala> foo(10)
res1: Option[Int] = Some(10)

 

--
Paul Phillips      | All men are frauds.  The only difference between
Apatheist          | them is that some admit it.  I myself deny it.
Empiricist         |     -- H. L. Mencken
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

scala> object foo {
     | def apply[T](t : T) : Option[T] = if (t == null) None else Some(t)
     | def apply[T](t : Option[T]) : Option[T] = t
     | }
defined module foo

scala> foo(Some(10))
res0: Option[Int] = Some(10)

scala> foo(10)
res1: Option[Int] = Some(10)

There's still one other boundary condition to think about, what about:
scala> val x : Option[Int] = nullx: Option[Int] = null
scala> foo(x)res2: Option[Int] = null

Otherwise, I vote to submit it as a patch to the library :) 

On Fri, Sep 04, 2009 at 04:19:07PM +0100, Kevin Wright wrote:
> I'm wondering if Option.apply() should maybe check if the supplied
> argument is already an Option, then return it unchanged if so.

And what would the type signature of that method be? (Try to write it.)

On Fri, Sep 4, 2009 at 5:27 PM, Viktor Klang <viktor.klang@gmail.com> wrote:

On Fri, Sep 4, 2009 at 5:20 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Sep 04, 2009 at 04:19:07PM +0100, Kevin Wright wrote:
> I'm wondering if Option.apply() should maybe check if the supplied
> argument is already an Option, then return it unchanged if so.

And what would the type signature of that method be? (Try to write it.)

scala> object foo {
     | def apply[T](t : T) : Option[T] = if (t == null) None else Some(t)
     | def apply[T](t : Option[T]) : Option[T] = t
     | }
defined module foo

scala> foo(Some(10))
res0: Option[Int] = Some(10)

scala> foo(10)
res1: Option[Int] = Some(10)

or, perhaps even more accurately:

scala> object foo {
     | def apply[T](t : T) : Option[T] = if(t == null) None else Some(t)
     | def apply[T](t : Option[T]) : Option[T] = if(t == null) None else t
     | }
defined module foo

scala> foo(null)
res2: Option[Nothing] = None

scala> foo(Some(10))
res3: Option[Int] = Some(10)

scala> foo("ninja")
res4: Option[java.lang.String] = Some(ninja)

scala> foo(null.asInstanceOf[Option[String]])
res5: Option[String] = None


 

 

--
Paul Phillips      | All men are frauds.  The only difference between
Apatheist          | them is that some admit it.  I myself deny it.
Empiricist         |     -- H. L. Mencken
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

So, we have any committers on this thread?

On Fri, Sep 4, 2009 at 4:35 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Beat you to it ;)

You did :) 

On Fri, Sep 04, 2009 at 05:37:06PM +0200, Viktor Klang wrote:
> Only _THE_ committer, Paul P.

I think you guys are a little too impressed with overloading as a
solution to anything. If your "null cleaner" isn't bulletproof then it
buys you very little.

scala> val x: AnyRef = Some(null)
x: AnyRef = Some(null)

scala> foo2(x)
res0: Option[AnyRef] = Some(Some(null))

scala> List(Some("abc"), "def") map (x => foo2.apply(x))
res1: List[Option[java.lang.Object]] = List(Some(Some(abc)), Some(def))

Ahh, I see your point :)Of course that wouldn't work
Perhaps overloading withdef apply[A](x: Option[A])would do the trick?

On Fri, Sep 4, 2009 at 4:22 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

How about this?
def apply[A](x: A): Option[A] = {  x match {    case Option[_] => x     case _ => if (x == null) None else Some(x)  }}

On Fri, Sep 4, 2009 at 4:20 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Sep 04, 2009 at 04:19:07PM +0100, Kevin Wright wrote:
> I'm wondering if Option.apply() should maybe check if the supplied
> argument is already an Option, then return it unchanged if so.

And what would the type signature of that method be? (Try to write it.)

--
Paul Phillips      | All men are frauds.  The only difference between
Apatheist          | them is that some admit it.  I myself deny it.
Empiricist         |     -- H. L. Mencken
pal, i pill push   |----------* http://www.improving.org/paulp/ *----------

Beat you to it ;)

You did :) 

On Fri, Sep 4, 2009 at 5:33 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

scala> object foo {
     | def apply[T](t : T) : Option[T] = if (t == null) None else Some(t)
     | def apply[T](t : Option[T]) : Option[T] = t
     | }
defined module foo

scala> foo(Some(10))
res0: Option[Int] = Some(10)

scala> foo(10)
res1: Option[Int] = Some(10)

There's still one other boundary condition to think about, what about:
scala> val x : Option[Int] = nullx: Option[Int] = null
scala> foo(x)res2: Option[Int] = null

Otherwise, I vote to submit it as a patch to the library :) 

Beat you to it ;)
 


--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

So we additionally need to flatten any arbitrary nesting of Options.
i.e.:
null -> Nonenull : Option[T] -> NoneNone -> NoneSome(null) -> None Some(Some(null)) -> NoneSome(Some(Some(null))) -> Noneetc...x -> Some(x)Some(x) -> Some(x)Some(Some(x)) -> Some(x)Some(Some(Some(x))) -> Some(x) etc...
All of the above match either T or Option[T], so our two overloaded methods are sufficient.  Have I missed any more cases?

On Fri, Sep 4, 2009 at 4:44 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Sep 04, 2009 at 05:37:06PM +0200, Viktor Klang wrote:
> Only _THE_ committer, Paul P.

I think you guys are a little too impressed with overloading as a
solution to anything.  If your "null cleaner" isn't bulletproof then it
buys you very little.

scala> val x: AnyRef = Some(null)
x: AnyRef = Some(null)

scala> foo2(x)
res0: Option[AnyRef] = Some(Some(null))

scala> List(Some("abc"), "def") map (x => foo2.apply(x))
res1: List[Option[java.lang.Object]] = List(Some(Some(abc)), Some(def))

--
Paul Phillips      | Every election is a sort of advance auction sale
Future Perfect     | of stolen goods.
Empiricist         |     -- H. L. Mencken
up hill, pi pals!  |----------* http://www.improving.org/paulp/ *----------

On Fri, Sep 4, 2009 at 5:36 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

So, we have any committers on this thread?

Only _THE_ committer, Paul P.
 

On Fri, Sep 4, 2009 at 4:35 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

Beat you to it ;)

You did :) 

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub

Of course Some.apply(x) needs to be verboten, and Option.apply(x) needs to do an instanceOf check

On Sep 4, 2009 5:44 PM, "Paul Phillips" <paulp@improving.org> wrote:

On Fri, Sep 04, 2009 at 05:37:06PM +0200, Viktor Klang wrote: > Only _THE_ committer, Paul P.

I think you guys are a little too impressed with overloading as a
solution to anything.  If your "null cleaner" isn't bulletproof then it
buys you very little.

scala> val x: AnyRef = Some(null)
x: AnyRef = Some(null)

scala> foo2(x)
res0: Option[AnyRef] = Some(Some(null))

scala> List(Some("abc"), "def") map (x => foo2.apply(x))
res1: List[Option[java.lang.Object]] = List(Some(Some(abc)), Some(def))

--
Paul Phillips      | Every election is a sort of advance auction sale
Future Perfect     | of stolen goods.
Empiricist         |     -- H. L. Mencken
up hill, pi pals!  |----------* http://www.improving.org/paulp/ *----------

On Fri, Sep 04, 2009 at 04:58:44PM +0100, Kevin Wright wrote:
> All of the above match either T or Option[T], so our two overloaded
> methods are sufficient. Have I missed any more cases?

I don't know, but let's just say it's unlikely this is going to set off
a race to commit it to trunk. If you guys want to assemble a slightly
more formal document with a proposed implementation and evidence that
all the bases are covered, I encourage you to do so:

http://www.scala-lang.org/node/233

On Fri, Sep 04, 2009 at 05:26:27PM +0100, Kevin Wright wrote:
> I think that Some.apply() should remain a valid construct, but
> attempting to construct Some(null) should - arguably - be considered a
> runtime error.

You need to review all the past discussion on this. Whatever you are
proposing, it can't disallow Some(null). Has to be a different Option
if you want to exclude that, otherwise you break the entire library.

List(null, "abc") find (_ != "abc")

Of course Some.apply(x) needs to be verboten

Ouch, that would break a lot of existing code.
I think that Some.apply() should remain a valid construct, but attempting to construct Some(null) should - arguably - be considered a runtime error.

A bigger concern of mine is the situation where:- you start with a nullable val (call it x), and wrap it via Option.apply()- in a later refactoring, x is changed to become an Option, so the wrapper is now returning an Option[Option]
I know that the refactoring should also include removal of the wrapper, but it's an easy one to miss.  Due to type inferencing, I can imagine some nasty compiler errors here that happen several miles away from the point at which the nesting occurs

More broadly, would it *ever* make sense to have nested options (i.e. Option[Option] or Option[Option[Option]])?  Perhaps this is something that the compiler could emit a warning for.

So all we need now is to disallow null in Lists too :)

On Fri, Sep 4, 2009 at 5:30 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Sep 04, 2009 at 05:26:27PM +0100, Kevin Wright wrote:
> I think that Some.apply() should remain a valid construct, but
> attempting to construct Some(null) should - arguably - be considered a
> runtime error.

You need to review all the past discussion on this.  Whatever you are
proposing, it can't disallow Some(null).  Has to be a different Option
if you want to exclude that, otherwise you break the entire library.

 List(null, "abc") find (_ != "abc")

--
Paul Phillips      | Every normal man must be tempted at times
Moral Alien        | to spit on his hands, hoist the black flag,
Empiricist         | and begin to slit throats.
pal, i pill push   |     -- H. L. Mencken

Ok,

will this catch most of the problems?

object foo {
      def apply[T](t : T) : Option[T] =
         t match {
            case x if x.isInstanceOf[Option[_]] => x.asInstanceOf[Option[T]]
            case x if x != null => Some(x)
            case _ => None
      } 
}

It will preserve Some(null)


On Fri, Sep 4, 2009 at 6:32 PM, Kevin Wright <kev.lee.wright@googlemail.com> wrote:

So all we need now is to disallow null in Lists too :)

On Fri, Sep 4, 2009 at 5:30 PM, Paul Phillips <paulp@improving.org> wrote:

On Fri, Sep 04, 2009 at 05:26:27PM +0100, Kevin Wright wrote:
> I think that Some.apply() should remain a valid construct, but
> attempting to construct Some(null) should - arguably - be considered a
> runtime error.

You need to review all the past discussion on this.  Whatever you are
proposing, it can't disallow Some(null).  Has to be a different Option
if you want to exclude that, otherwise you break the entire library.

 List(null, "abc") find (_ != "abc")

--
Paul Phillips      | Every normal man must be tempted at times
Moral Alien        | to spit on his hands, hoist the black flag,
Empiricist         | and begin to slit throats.
pal, i pill push   |     -- H. L. Mencken

--
Viktor Klang

Blog: klangism.blogspot.com
Twttr: viktorklang

Lift Committer - liftweb.com
AKKA Committer - akkasource.org
Cassidy - github.com/viktorklang/Cassidy.git
SoftPub founder: http://groups.google.com/group/softpub