In some code we have (a Newtonsoft.JSON parsing that calls IndexOf, which calls into the Equals method of XLStyle), it currently fails because of the following code:
```csharp
public override bool Equals(object obj)
{
return Equals((XLStyle)obj);
}
```
this assumes that any object is definitely an `XLStyle` at this point, which may not be the case. (In our instance, it appears to be checking a XLFont object). Regardless, defense programming would suggest the need to be a little more cautious rather than directly casting.
In this case, we'd expect want any object that isn't an XLStyle (or at least that implements IXLStyle) to return false, and otherwise go into the comparison.
We'll submit a patch to fix this in a few areas and will test it in our application to see if it resolves the issue first. Essentially, it would insert a guard clause, e.g. `if (!obj is IXLStyle){ return false; }` to ensure that the casting issue doesn't happen.
Interested in thoughts, but this seems pretty straightforward at first glance.
```csharp
public override bool Equals(object obj)
{
return Equals((XLStyle)obj);
}
```
this assumes that any object is definitely an `XLStyle` at this point, which may not be the case. (In our instance, it appears to be checking a XLFont object). Regardless, defense programming would suggest the need to be a little more cautious rather than directly casting.
In this case, we'd expect want any object that isn't an XLStyle (or at least that implements IXLStyle) to return false, and otherwise go into the comparison.
We'll submit a patch to fix this in a few areas and will test it in our application to see if it resolves the issue first. Essentially, it would insert a guard clause, e.g. `if (!obj is IXLStyle){ return false; }` to ensure that the casting issue doesn't happen.
Interested in thoughts, but this seems pretty straightforward at first glance.