The number of exceptions thrown should be reduced. This may affect performance.

[ShiinaSekiu]

signum/indispensable/src/commonMain/kotlin/at/asitplus/signum/indispensable/asn1/Asn1Elements.kt

Lines 432 to 443 in e8f9bd4

	/**
	* Returns the next child held by this structure. Useful for iterating over its children when parsing complex structures.
	* @throws [Asn1StructuralException] if no more children are available
	*/
	@Throws(Asn1StructuralException::class)
	fun nextChild() =
	catching { children[index++] }.getOrElse { throw Asn1StructuralException("No more content left") }
	/**
	* Exception-free version of [nextChild]
	*/
	fun nextChildOrNull() = catching { nextChild() }.getOrNull()

        /**
         * Returns the next child held by this structure. Useful for iterating over its children when parsing complex structures.
         * @throws [Asn1StructuralException] if no more children are available
         */
        @Throws(Asn1StructuralException::class)
        fun nextChild() = children.getOrElse(index++) { throw Asn1StructuralException("No more content left") }

        /**
         * Exception-free version of [nextChild]
         */
        fun nextChildOrNull() = children.getOrNull(index++)

[JesusMcCloud]

Thank you very much! There are probably a handful of locations, where it is possible to get around throwing and catching.
The more pressing issue wrt. performance is not rooted in this project, though, but in KmmResult, which cannot be a value class, as it would make it impossible to export it to an XC framework. Thus, catching incurs a performance hit. At the same time runCatching catches more than it should, so we require catching.

[ShiinaSekiu]

By the way, why doesn't the peek() method of this class have a corresponding peekOrNull() method?

[JesusMcCloud]

I'll note that down for improving API docs. peek already returns null, if no more children are left. All the feedback you have provided so far is really appreciated!

[JesusMcCloud]

The improved docs are part of #151

[JesusMcCloud]

KmmResult 1.9.0 will be part of the next release, significantly reducing overhead, even though the same number of exceptions are thrown.

[iaik-jheher]

KmmResult 1.9.0 will be part of the next release, significantly reducing overhead, even though the same number of exceptions are thrown.

This would require us to go through and review catching uses/convert them to catchingUnwrapped, to my understanding?

[JesusMcCloud]

I think we can close this when #229 is through. After all, the critical parts throwing exceptions are mostly IO (encoding/decoding) where you do want to throw, when things go south. I know this does not cover everything perfectly, because we also internally use public API methods that instantiate a KmmResult and don't care for it, but I'd say were 95% there.

If this issue remains stale, I'll close it