Improved errorhandling

It took a while to figure out how to convert this exception to normal control flow. Typescript adds some extra difficulty. It is pretty ugly....

    catch ( e ) {
        if ( Object.prototype.toString.call(e) === '[object Error]') {
            const e2 = e as Error
            if ( e2['code' as keyof typeof e2 ] === '22003'  ) {
                const detail: string | unknown = e2['detail' as keyof typeof e2]
                if ( detail ) {
                    logger.debug(`detail=${JSON.stringify(detail)}`)
                    return new UserError(detail.toString())
                }
                else {
                    logger.error(`sp_breedsimm_create_v1: Caught and rethrowing ${JSON.stringify(e2)} for indata ${JSON.stringify(params, undef_replacer)}`)
                    throw e
                }
            }
            else {
                logger.error(`sp_breedsimm_create_v1: Caught and rethrowing ${JSON.stringify(e2)} for indata ${JSON.stringify(params, undef_replacer)}`)
                throw e
            }
        }
        else {
            logger.error(`sp_breedsimm_create_v1: Caught and rethrowing ${JSON.stringify(e)} of type ${Object.prototype.toString.call(e)} for indata ${JSON.stringify(params, undef_replacer)}`)
            throw e
        }

If a new class with a constructor is used maybe the above code could be converted to :

    catch ( e ) {
            const e2 = e as PostgresError
            if ( e2.code === '22003'  ) {
                const = e2.detail
                logger.debug(`detail=${JSON.stringify(detail)}`)
                return new UserError(detail.toString())
            }
            else {
                logger.error(`sp_breedsimm_create_v1: Caught and rethrowing ${JSON.stringify(e2)} for indata ${JSON.stringify(params, undef_replacer)}`)
                throw e
            }

While you are at it maybe even catergorize the errors? Separate classes for where or how the error can be solved, or a new property. I propose these categories, programming, configuration, retryable, user. A programming error must be solved by changing the code. Configuration should be solved by changing the configuration of the deployment. Retryable is typcally solved by retrying after a delay. User is is solved by supplying different indata.

Start from the catch block shown in the issue and the PostgreSQL error code 22003 handling around sp_breedsimm_create_v1. Determine whether the proposed PostgresError class and programming, configuration, retryable, and user categories fit the project's existing error behavior; done requires an agreed design and corresponding coverage for the affected error paths.