Incorrect prediction for hashCode() method on Exception class

Issue #801 new
Chuck Liddell created an issue

Incredibly trivial issue, feel free to disregard.

In the prediction list I am shown "hashCode()" as a possible method for instances of Exception (or extension classes of Exception). I imagine you've hardcoded hashCode() since every class is supposed to have it.

However, the Exception class is, pun-accepted, an exception. Calling hashCode() on an Exception instance yields:

Method does not exist or incorrect signature: void hashCode() from the type Exception

Ideally I would not be shown "hashCode()" as a possible prediction when I working with an Exception instance.

Comments (4)

  1. Scott Wells repo owner

    Thanks, Chuck. Yeah, it's happening because IC assumes that all classes extend Object including Exception and its derived types, and in the OST Object is generated with exactly three common methods: equals(), hashCode(), and toString(). Sounds like perhaps Exception should be considered its own distinct type hierarchy or something...though I bet it is assignable to Object. Let me investigate a bit...Exception has always been a weird one in Apex.

  2. Chuck Liddell reporter

    toString() is pretty hit or miss as well. Lots of things (most things?) don't support it. SObjects don't have it, Id doesn't have it.

    Account a = new Account(); a.toString();

    Integer i = 5; i.toString();

    Method does not exist or incorrect signature: void toString() from the type Account Method does not exist or incorrect signature: void toString() from the type Integer

  3. Chuck Liddell reporter

    To clarify, I'm pretty sure these all still exist behind the scenes (equals() powers Set equality, for example, and hashCode() powers Map key equality), just not invokable from the apex we get to write.

  4. Scott Wells repo owner

    Well, yes and no. Here's the thing that motivated me to add those to the shared Object base class:

    Object foo = 'bar';
    System.debug(foo.toString());
    System.debug(foo.hashCode());
    System.debug(foo.equals('bar'));
    
    Object account = new Account(Name = 'account');
    System.debug(account.toString());
    System.debug(account.hashCode());
    System.debug(account.equals(new Account(Name = 'account')));
    
    Object e = new SecurityException('Bad');
    System.debug(e.toString());
    System.debug(e.hashCode());
    System.debug(e.equals(new SecurityException('Bad')));
    

    That all compiles and runs just fine. All of those objects are in fact assignable to Object, and all of them then support equals(), hashCode(), and toString(). That's what I meant about these types being weird in Apex. You can invoke those methods on them polymorphically but not directly. As a result, IC errs toward the side of proper polymorphic behavior.

  5. Log in to comment