Refactor ErrorObject and Error classes' initialization #849
Conversation
Codecov Report
@@ Coverage Diff @@
## master #849 +/- ##
=======================================
Coverage 81.02% 81.03%
=======================================
Files 54 54
Lines 7496 7498 +2
=======================================
+ Hits 6074 6076 +2
Misses 1188 1188
Partials 234 234
Continue to review full report at Codecov.
|
| @@ -22,7 +22,6 @@ type Error struct { | |||
| message string | |||
| stackTraces []string | |||
| storedTraces bool | |||
| Type string | |||
There was a problem hiding this comment.
The Type attribute is essentially the error's class name. So we don't need to store it separately.
Currently, we allow raising errors from vm with any given string. This is a bad practice because any internal error should have a corresponding error class. This PR fixes this by only accepting pre-defined error types (enum) when initializing error objects. It also checks every error type (int) has a corresponding name (string) during vm initialization, which saves us the work to visually sync the 2 lists manually.
There was a problem hiding this comment.
For some reason, I'm not 100% convinced of the new logic. If the purpose is to avoid:
raising errors from vm with any given string, [...] This is a bad practice because any internal error should have a corresponding error class
wouldn't defining the ErrorType type to string do the work? the enum could then use ErrorType rather than plain strings.
I'm not familiar with Go, so I may be wrong.
Currently, we allow raising errors from
vmwith any given string, likeThis is a bad practice because any internal error should have a corresponding error class.
This PR fixes this by only accepting pre-defined error types (enum) when initializing error objects. It also checks every error type (int) has a corresponding name (string) during vm initialization, which saves us the work to visually sync the 2 lists manually.