This page is no longer maintained — Please continue to the home page at www.scala-lang.org

Adding ??? to Predef?

103 replies
DaveScala
Joined: 2011-03-18,
User offline. Last seen 1 year 21 weeks ago.
Re: Adding ??? to Predef?

> Figuring out whether something is supposed to be an Error or an
> Exception by parsing the Java API documentation probably ascribes to
> that documentation a level of language-lawyeriness that it wasn't
> designed to possess. I suspect a better guide is the fact that
> AssertionError is an Error, and it does seem to me that ??? is
> reasonably close in spirit to AssertionError.
>
I find all Unsupported...Exceptions also "reasonably close in spirit".
So that becomes very idiosyncratic and vague and whose spirit is it
anyway, yours, mine, everybody's? Might be different for everybody.
And referring to the fact "AssertionError is an Error" is actually
language-lawyeriness, because how do you know for sure that it is a
fact anyway? What if it is an Exception? If it quacks like a duck it
might still be an mp3-player. Asking the spirit for help has something
religious, monomanic and egocentric in your argument: "it's close to
my spirit so it must be right, follow me".

roland.kuhn
Joined: 2011-02-21,
User offline. Last seen 35 weeks 3 days ago.
Re: Adding ??? to Predef?

Simple answer from the docs: “An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.” In this sense I very much agree with the choice of having ??? throw an Error.

Regards,

Roland

On Oct 10, 2011, at 19:23 , Archontophoenix Quar wrote:

> If an Error is a condition that "should never occur", that suggests
> that you "should never" try to run a program of which you know pieces
> are missing, assuming that those missing pieces constitute an Error
> (as opposed to an Exception).
>
> Well, you know a program with pieces missing is not going to run
> successfully if you launch it. Does that mean you're not seriously
> trying to run it when you launch it?
>
> Figuring out whether something is supposed to be an Error or an
> Exception by parsing the Java API documentation probably ascribes to
> that documentation a level of language-lawyeriness that it wasn't
> designed to possess. I suspect a better guide is the fact that
> AssertionError is an Error, and it does seem to me that ??? is
> reasonably close in spirit to AssertionError.
>
> A
>
> On Mon, Oct 10, 2011 at 3:56 AM, Dave wrote:
>> I agree that Error is better because a try catch clause around ???
>> would make no sense which is the intention of Errors: Throwables that
>> you should not try to catch.
>>
>> "An Error is a subclass of Throwable that indicates serious problems
>> that a reasonable application should not try to catch. Most such
>> errors are abnormal conditions. The ThreadDeath error, though a
>> "normal" condition, is also a subclass of Error because most
>> applications should not try to catch it.
>>
>> A method is not required to declare in its throws clause any
>> subclasses of Error that might be thrown during the execution of the
>> method but not caught, since these errors are abnormal conditions that
>> should never occur."
>> see: http://download.oracle.com/javase/6/docs/api/java/lang/Error.html
>>
>> So I interpret this as:
>> if
>>
>> try{ ???
>> } catch {
>>
>> }
>>
>> makes no sense then ??? should raise an Error not an Exception.
>>
>>
>>

Roland Kuhn
Typesafe – Enterprise-Grade Scala from the Experts
twitter: @rolandkuhn

Som Snytt
Joined: 2011-09-19,
User offline. Last seen 42 years 45 weeks ago.
Re: Adding ??? to Predef?
This was the basis of my previous comment:

<<I'd have gone with UnimplementedOperationException.  If it's an Error, an otherwise "reasonable application" such as some TA's ClassAssignmentRunner will have to catch it in order to fail(exercise).>>

On further reflection, I'd distinguish applications and frameworks.  Frameworks like junit or the hypothetical ClassAssignmentRunner catch throwables that well-behaved applications do not.  So I'm reconciled to an Error.

On the other hand, Errors are supposed to be mitigated at compile time, so it seems to me more obvious that compiler support of some kind is called for.  Save me from myself.

I like the idea of using @elidable to warn about leftover usages of ???.  Instead of eliding to something innocuous (BoxedUnit), elide to something that breaks the build.

If anyone still uses the MOSCOW acronym for prioritizing features, I could imagine features stubbed in this way:

def vanilla = should???
def fancy = could???

where
@elidable(level=Production, break=true, warn=500) def should??? ...
means that should??? will break the build on elision and emit warnings when the elision level is within "500" of Production.

Instead of saying a project is at "code complete" or "feature freeze", we could say a project is at elision level "Production" or "2000", and any required or desired features must be implemented, or the build will break.

I don't code this way currently, but maybe I would if I had such a facility.

People have compared the ??? exception to UnsupportedOperation, so I grepped it (in the jdk).  The paradigmatic usage is for Collections that don't honor the contract interface (like immutables throwing on add).  (Yes, in Scala this seems barbaric.)  But the exception is often a proxy for IllegalStateException or even IllegalArgument.  (E.g., Instrumentation.addTransformer perhaps should throw IllegalState.)

E.g., throw new UnsupportedOperationException("Not supported yet.");
Doesn't that mean ??? ?

I grepped my own lib code and found the same sentiment:
throw new UnsupportedOperationException("Multiline format is not yet supported");
which means I will someday, it's not like an immutable collection throwing on add.

If graphics hardware doesn't support an operation, that's clearly an UnsupportedOperation; but if I'm working out the kinks in some code and by the way, I may not find time to get around to fixing it, is that Unsupported or merely NotYetGottenAroundToItError?

I had to share MappedByteBuffer -- this is clearly IllegalState, since the code literally checks state -- but luckily the user doesn't see the inline comment about the "luser" who invokes it --
    private void checkMapped() {
        if (!isAMappedBuffer)
            // Can only happen if a luser explicitly casts a direct byte buffer
            throw new UnsupportedOperationException();
    }

Possibly, IllegalState, UnsupportedOperation, et al, should just derive from a common super, "AintGonnaHappenException".


On Mon, Oct 10, 2011 at 3:51 PM, Roland Kuhn <google [at] rkuhn [dot] info> wrote:
Simple answer from the docs: “An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch.” In this sense I very much agree with the choice of having ??? throw an Error.

Regards,

Roland

On Oct 10, 2011, at 19:23 , Archontophoenix Quar wrote:

> If an Error is a condition that "should never occur", that suggests
> that you "should never" try to run a program of which you know pieces
> are missing, assuming that those missing pieces constitute an Error
> (as opposed to an Exception).
>
> Well, you know a program with pieces missing is not going to run
> successfully if you launch it. Does that mean you're not seriously
> trying to run it when you launch it?
>
> Figuring out whether something is supposed to be an Error or an
> Exception by parsing the Java API documentation probably ascribes to
> that documentation a level of language-lawyeriness that it wasn't
> designed to possess. I suspect a better guide is the fact that
> AssertionError is an Error, and it does seem to me that ??? is
> reasonably close in spirit to AssertionError.
>
> A
>
> On Mon, Oct 10, 2011 at 3:56 AM, Dave <dave [dot] mahabiersing [at] hotmail [dot] com> wrote:
>> I agree that Error is better because a try catch clause around ???
>> would make no sense which is the intention of Errors: Throwables that
>> you should not try to catch.
>>
>> "An Error is a subclass of Throwable that indicates serious problems
>> that a reasonable application should not try to catch. Most such
>> errors are abnormal conditions. The ThreadDeath error, though a
>> "normal" condition, is also a subclass of Error because most
>> applications should not try to catch it.
>>
>> A method is not required to declare in its throws clause any
>> subclasses of Error that might be thrown during the execution of the
>> method but not caught, since these errors are abnormal conditions that
>> should never occur."
>> see: http://download.oracle.com/javase/6/docs/api/java/lang/Error.html
>>
>> So I interpret this as:
>> if
>>
>> try{ ???
>> } catch {
>>
>> }
>>
>> makes no sense then ??? should raise an Error not an Exception.
>>
>>
>>

Roland Kuhn
Typesafe – Enterprise-Grade Scala from the Experts
twitter: @rolandkuhn


Copyright © 2012 École Polytechnique Fédérale de Lausanne (EPFL), Lausanne, Switzerland