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.
2 条评论