Timeline for Inheriting from Abstract class vs Enum Types for custom exceptions
Current License: CC BY-SA 3.0
5 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Nov 20, 2014 at 15:37 | vote | accept | Yogesh | ||
Aug 11, 2014 at 23:01 | comment | added | radarbob |
"Inherit from Abstract Class" but we're discussing interface , i.e. the C# keyword yes? So why not a templated abstract class? The virtual methods are called within the abstract "code framework" and give the Director context for knowing what exception to throw. You may have to design a ReturnResult class so the communication is rich enough to make intelligent decisions; that is to say, object oriented. This does not have to conflict with @Magus comment, that I up-voted.
|
|
Jul 30, 2014 at 14:27 | comment | added | Magus | You're looking at this from the wrong direction, I think. Exceptions are for exceptional situations, things that should usually result in a crash. They are not equivalent to events you want to handle. Why is there authentication happening in a plugin? Is it connecting to a database? Then it's the plugin's issue to solve, not the director's. If it's to determine whether or not the plugin is authentic, that is the director's job. Timeouts are the same thing. Ultimately, you need to send a message back with a result, but if it's one you never want to result in a crash, it's not an exception. | |
Jul 30, 2014 at 13:25 | comment | added | Yogesh | My director needs to know if there was an authentication problem (fatal) or a timeout (non-fatal) because based on the type of exception it needs to decide further actions. For example: if it was an authentication problem director needs to stop further communication with the plugin until the authentication problem is resolved. Also based on the exception, director will have to inform the appropriate admin to look at the issue. | |
Jul 29, 2014 at 23:02 | history | answered | Magus | CC BY-SA 3.0 |