浏览器在尝试创建渲染上下文时是否会抛出错误？

Question

以下代码是否会抛出错误？

var canvas = document.createElement("canvas");

var ctx = canvas.getContext("somethingwrong");

在铬中,它只返回null.

如果浏览器知道请求的渲染上下文怎么样？(比如"webgl"或"experimental-webgl")是否有可能出现错误异常？在铬中,我无法引发这种行为.

换句话说:我是否需要将此代码包装在库中的try/catch中,以便干净地检查渲染上下文？

有没有办法可以客观化这个？例如,通过Web服务尝试在不同浏览器中剪切的代码并列出它们可能不同的结果.

Answer 1

如果请求的上下文不可用，或者画布已分配给不同类型的上下文，则返回null是预期的行为：

null如果不支持给定的上下文 ID，如果画布已使用其他上下文类型初始化（例如，在获取“webgl”上下文后尝试获取“2d”上下文），则返回。

在某些特殊情况下，可能会抛出与代理场景相关的异常（同上）：

InvalidStateError如果使用了setContext()或 方法，则抛出异常。transferControlToProxy()

除此之外，即使浏览器可能支持某种类型的上下文，也不能保证如果系统资源（例如内存）较低（在这种情况下会null返回），则可以创建该对象。

以下是不同（常见）场景中返回内容的概述。

因此，除非您使用代理传输（目前尚未得到广泛支持），否则您不需要使用try-catchwith getContext()。

提示：将来canvas将获得一个probablySupportsContext()可以在之前使用的属性getContext()。这将执行这些测试并false在不满足条件时返回（支持的上下文、已在不同上下文类型中使用、资源不足等）：

var supported = canvas . probablySupportsContext(contextId [, ... ] )

如果使用getContext()相同的参数调用肯定会返回 null，则返回 false，否则返回 true。

更新只是想详细说明一个特殊情况 - 对于供应商特定的扩展，理论上可能会抛出异常，具体取决于该非常特定的扩展及其定义其行为的方式。但这些是且不应该被视为标准的一部分，并且由于它们在大多数情况下都是实验性的，因此暗示着风险和非标准行为。