Re: When is a function not a function?

Matt Kruse wrote:
On Nov 26, 5:12 pm, Richard Cornford wrote:
> var o = document.createElement("object");
> alert(typeof o); // "function"
> o(); // ERROR
In Firefox, when you call an object that is not callable
the exception thrown is "o is not a function", but the
exception here is "Component is not available", so you
cannot prove that the object is not callable, only that
calling it throws an exception.

This gets into a pretty gray area, then, doesn't it?

It suggests that there is limited use in knowing that something is callable.

How could you ever know that _any_ object that is
callable will not result in an error?

By knowing what it is you are calling (say knowing that - document.getElementById - is forbidden from throwing an exception) or by testing that conditions that would result in an exception being thrown don't apply before taking actions that may result in their being thrown.

Should everything be wrapped in a try/catch?

Almost nothing should be wrapped in try-catch because javascript's exception handling is far too poor to allow sensible error handling. Defensive programming to avoid runtime errors is a far superior approach.

Your original statement was:
You might reasonably say that if - typeof x - was
'function' then it would be safe to call the object,
and be correct in all the environments that I have
ever encountered.

so I was trying to demonstrate a situation where it is
not in fact "safe" to call an object with
typeof=="function".

And you did not do that.

If by "safe" you
mean "won't throw an error".

The act of calling the object has not been shown to throw an error. Instead the consequence of calling; the resulting execution of code, appears to be where the exception is occurring.

The bottom line is that an object's being callable is no
guarantee that calling will be an error free operation.

But if you extend that to the absurd, then you have no
guarantee that calling something like alert() will be
an error free operation, do you?

Fortunately browsers are rarely absurd. Remember that you started off trying to call the object returned from - document.createElement("object") - without any reason for expecting that to have any certain outcome at all.

I think it should be safe to conclude that anything
reporting itself as typeof=="function" should be
callable without throwing an error,

Don't be ridiculous. Even programmer defined functions are allowed to throw exceptions while they execute.

Remember that host methods may throw exceptions if they receive the wrong number or type of arguments (that is pretty common) and knowing that something is callable will not tell you anything about the arguments that it is expecting when it is called.

and in this case FF has a bug.

What makes it a bug?

Nevertheless, it's a bug that needs to be worked
around in any code that is trying to figure out if a given
object should be treated as a callable function.

Given that knowing something is callable is never enough to tell you that calling it will be error free you are just describing a stupid design and then saying that the aspects of the design that make it stupid become a problem in context.

Don't design code that attempts to call function/methods without first having a very good idea of what those functions/method are, and what the consequences of calling them is likely to be.

The root cause of this mess in jQuery seems to be that
the API tries to "overload" methods to handle various
types of arguments, like

func(object, object)
or
func(object, function)

so there is a "need" to figure out which type of
method signature is being called.

Maybe, but we have already discovered that JQuery written by a novice who is far too arrogant to even consider whether he has made any mistakes, let alone recognise the ones he has made. How often have we witnessed that superficial success in the early stages of learning javascript result in individuals acquiring a total unrealistic overconfidence in their own abilities?

I do tend to like this kind of "overloading" in many
cases because it results in very dense and flexible code,
but given the problems involved in truly testing whether
an argument is a callable function,

But clearly the issue is not whether the argument is callable or not. We have seen that that information alone is not sufficient here. You certainly learn nothing about the number and type of any possibly required arguments from that information, and that is just the start of the ongoing problems with such a reckless strategy.

I think this design decision is a flaw.

Absolutely, but what chance of it being fixed in this library? The fix would radically alter the nature of the API, and so render all pre-existing code that uses the library non-updateable. It is a pity that the people who make these things do not spend some time learning the browser scripting issues before they start because then they may be able to avoid tying hundreds of other people's projects to their ill thought out code.

Richard.

.

Relevant Pages

  • RE: .NET Runtime 2.0 Error - I need more details...
    ... so if you can not use this event to handle the exception. ... The default event logging behavior of console application is built into ... ConsoleException.Program.Main), calling mscorwks!JIT_Throw ... Microsoft Online Community Support ...
    (microsoft.public.dotnet.framework)
  • Re: Assertion on Type conversion
    ... The author states that "if a method has specified some pre-condition then the failure of that condition is the responsibility of the ... depends on the caller's ability to check for conditions, and assure them to be correct, prior to the calling of the method. ... An overlooked exception that could be handled gracefully. ... Implement a method like "IsValid" to do a runtime check first if your concerned about the ArgumentException being thrown. ...
    (microsoft.public.dotnet.languages.csharp)
  • RE: Microsoft.XLANGs.RuntimeTypes.InvalidPropertyTypeException
    ... Trying to access a data property on a message for which it has not ... Yes the exception is of significant concern; it is a major user error. ... Any exception thrown could delay the cleanup of resources, ... System.Text.StringBuilder.Append), calling mscorsvr!Ordinal76+0x1d925 ...
    (microsoft.public.biztalk.server)
  • Microsoft.XLANGs.RuntimeTypes.InvalidPropertyTypeException
    ... they still occur when we turn tracking off. ... Is this 'exception' of a significant concern? ... System.Text.StringBuilder.Append), calling mscorsvr!Ordinal76+0x1d925 ...
    (microsoft.public.biztalk.server)
  • Re: When is a function not a function?
    ... In Firefox, when you call an object that is not callable the exception thrown is "o is not a function", but the exception here is "Component is not available", so you cannot prove that the object is not callable, only that calling it throws an exception. ... So this is not your mistake, you just didn't think about it enough to see who was being fooled here. ...
    (comp.lang.javascript)