If you want to know the map state of a GPUBuffer, you can track the state yourself and update it each time you createBuffer/mapAsync/unmap. This is a fine pattern. However in some cases, if you happen to also need to getMappedRange, you can use the exception thrown from getMappedRange() instead. This isn't great because it (1) encourages authors to depend on exception results, and (2) doesn't allow distinguishing from other errors in getMappedRange() (except by looking at the exception message which is implementation-defined and non-stable).

There are two things we could do about this (either or both):

• Make the state-check in getMappedRange() produce an error in a different way, either return null (Return null from getMappedRange if mapping is pending #3010) or throw a different exception type.
• Directly expose the state of the buffer as a readonly attribute (TBD what the granularity of that state enum is). Expose the buffer state as an attribute #3014