Timeline for When to create a custom exception in C#
Current License: CC BY-SA 3.0
6 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 2, 2015 at 23:49 | comment | added | Robert Harvey | You can provide a detailed error message in whatever exception you throw. Unless you plan on using specific exceptions to provide programmatic control to the caller, I think creating a custom exception is a waste of time. Don't take my word for it, read this, which says "Create your own user-defined exceptions if you want users to be able to programmatically distinguish between some error conditions." | |
| Mar 2, 2015 at 23:38 | comment | added | Stephen | What value does it add? It adds plenty of value when documented properly. It says that this specific problem happened. It's not clear that the calling code cannot recover from this error. | |
| Mar 2, 2015 at 23:32 | comment | added | Robert Harvey | Pfft. A custom exception is not necessary. What other exception might the method throw, except whichever one that you chose? How does SetOperatingModeFailedException add any value beyond, say, InvalidOperationException? Neither exception tells you why the failure occurred, or gives you a way to respond programmatically based on the type of exception that was thrown. And creating new Exception classes is not cost-free. | |
| Mar 2, 2015 at 23:29 | comment | added | Stephen | Actually I did answer his questions. "I would allow any exceptions from the write operation bubble up." (i.e. don't bother checking if the port is opened) and "create a SetOperatingModeFailedException". | |
| Mar 2, 2015 at 23:26 | comment | added | Robert Harvey | You appear to have misunderstood what he's asking. Should he use one of the existing exception types, or roll his own? | |
| Mar 2, 2015 at 23:22 | history | answered | Stephen | CC BY-SA 3.0 |