Incorrect prediction for hashCode() method on Exception class

[Chuck Liddell]

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.

[Scott Wells]

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.

[Chuck Liddell]

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

[Chuck Liddell]

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.

[Scott Wells]

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.

[Scott Wells]

Issue tracker grooming. If this is still an issue, please feel free to reopen, ideally with a concrete reproduction scenario.