Timeline for Throw exception or let code fail
Current License: CC BY-SA 3.0
13 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot |
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
|
|
| Jan 24, 2015 at 17:07 | comment | added | Brandon | If I needed to call this method and had to deal with this exception case, it would definitely annoy me. After I write my own code to check if it contains the key, I would be sad to then find that the method checks it anyway. My if statement would be for the sole purpose of avoiding the exception. And if you declared it a checked exception, I would need an if statement and a catch clause. | |
| Jan 24, 2015 at 17:05 | comment | added | Brandon | FWIW, I agree with the idempotent approach. From the perspective of somebody calling this method, I have to check if the map contains key N, which is redundant, because the method already does it. Or, I have to catch an exception. I guess it depends on if it's considered a mistake in your design to call this twice for the same parameters. My preference is to handle the case rather than throw an exception, which will then need to be handled anyway. | |
| Jan 24, 2015 at 12:08 | comment | added | Warbo |
@l0b0 yes, I left it implicit that the parameters must be the same. Thanks for clarifying for those who may haven't come across the concept before :) Of course, in this case, it doesn't matter too much, since the if (_Materials.ContainsKey(name)) line will spot our previous parameters, and those of any other loading mechanism that's been used.
|
|
| Jan 23, 2015 at 21:10 | history | edited | gnat | CC BY-SA 3.0 |
link to the referred post
|
| Jan 23, 2015 at 17:30 | comment | added | Frank Hileman | Whether this is the correct strategy or not, really depends on the overall design of the system. A true precondition means that something will go wrong in the future, if that condition is not met. | |
| Jan 23, 2015 at 16:46 | comment | added | user949300 | I like this idea, but suggest one minor change: return a boolean reflecting whether anything was loaded. If caller really cares about application logic, they can check that and throw an exception. | |
| Jan 23, 2015 at 15:09 | comment | added | l0b0 |
@Warbo: Being idempotent means that running it many times with the same parameters has the same effect as running it once. So if you call LoadMaterial("foo") and then LoadMaterial("bar") you should expect the code to use bar, not foo.
|
|
| Jan 23, 2015 at 13:19 | comment | added | Benjamin Gruenbaum |
@Philipp if we think about it LoadMaterial has the following constraints: "After calling it the material is always loaded and the number of materials loaded did not decrease". Throwing an exception for a third constraint "The material cannot be added twice" seems silly and counterintuitive to me. Making the function idempotent reduces the code's reliance on execution order and application state. It seems like a double win for me.
|
|
| Jan 23, 2015 at 11:35 | comment | added | F.P | I like this more, actually. Of course, depending on the constraints given by the applications requirements, this might be wrong. Then again, I am an absolute fan of idempotent methods. | |
| Jan 23, 2015 at 10:51 | comment | added | Warbo | @Philipp the function would not fail silently. Being idempotent means that running it many times has the same effect as running it once. In other words, if the material is already loaded, then our spec ("the material should be loaded") is already satisfied, so we don't need to do anything. We can just return. | |
| Jan 23, 2015 at 10:01 | comment | added | Philipp | On the other hand, having a function fail silently can cause unexpected behavior resulting in harder to find bugs occuring later. | |
| Jan 23, 2015 at 3:25 | history | answered | Karl Bielefeldt | CC BY-SA 3.0 |