internal: Refactor DesignException handling to use unified DesignErrorCode enum#67
internal: Refactor DesignException handling to use unified DesignErrorCode enum#67
Conversation
|
⏳ I'm reviewing this pull request for security vulnerabilities and code quality issues. I'll provide an update when I'm done |
| cause | ||
| ) | ||
|
|
||
| case class DesignException(code: DesignErrorCode, message: String, cause: Throwable = null) |
There was a problem hiding this comment.
Description: DesignException class doesn't override getMessage method, which may lead to inconsistent error reporting. Override getMessage method in DesignException class to return a formatted string including the error code.
Severity: Medium
There was a problem hiding this comment.
The fix addresses the comment by overriding the getMessage method in the DesignException class to include the error code in the formatted string. The toString method is also updated to use the new getMessage implementation, ensuring consistent error reporting. This change provides a more informative error message that includes both the error code and the original message.
| case class DesignException(code: DesignErrorCode, message: String, cause: Throwable = null) | |
| case class DesignException(code: DesignErrorCode, message: String, cause: Throwable = null) | |
| extends Exception(message, cause): | |
| override def getMessage: String = s"[${code}] ${super.getMessage}" | |
| override def toString: String = getMessage | |
| object DesignException: | |
| def cyclicDependency(deps: List[Surface], sourceCode: SourceCode): DesignException = |
|
✅ I finished the code review, and left comments with the issues I found. I will now generate code fix suggestions. |
Description
Refactored
DesignExceptionhandling to integrate the use of a unifiedDesignErrorCodeenum, improving consistency and maintainability.Related Issue/Task
N/A
Checklist