@dstotijn

@dstotijn please

I agree that blockDTO.Block() shouldn't panic when an unsupported block type is encountered. But I wouldn't return a nil value and silently drop it in list responses. This could lead to unexpected/confusing behavior for users of the library.

I would rather change the signature of the Block method to func Block() (Block, error), and bubble up the error at all the call sites where Block is called. This will be a breaking change, but that's fine (we're at v0).

@bassettb Let me know if you want to make the aforementioned change on this PR, otherwise I can do it.

I agree that it's not an ideal solution. But unsupported blocks are extremely common. They are built into the API (type="unsupported"). And this package might be slow to support new types. Callers of FindBlockChildrenByID would rather get the supported blocks than get no blocks just because of a single unsupported block.

I updated the PR so that other callers of Block() can receive and handle any errors.