Timeline for How to name a method that both performs a task and returns a boolean as a status?
Current License: CC BY-SA 3.0
26 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 24, 2018 at 4:48 | comment | added | imgx64 | Related question: softwareengineering.stackexchange.com/questions/161753/… | |
| Apr 12, 2017 at 7:31 | history | edited | CommunityBot |
replaced http://programmers.stackexchange.com/ with https://softwareengineering.stackexchange.com/
|
|
| Jun 13, 2014 at 7:20 | vote | accept | Limbo Exile | ||
| Jun 12, 2014 at 19:11 | audit | Close votes | |||
| Jun 12, 2014 at 19:11 | |||||
| Jun 12, 2014 at 14:25 | comment | added | lilbyrdie | The answers, and discussion here, are in the realm of "use exceptions or not." Can you assume a call was successful if it doesn't throw an exception? If so, you'd never see a false result (in the specific example here, but just a getter or checker). Yet, this pattern is used everywhere. Database calls, network calls, file system calls, etc. often return a success or failed value. Put another way, false does not have to be an exception. In these scenarios, true and false could be equally weighted, neither being more exceptional than the other. | |
| Jun 12, 2014 at 13:37 | answer | added | Scott Rickman | timeline score: 1 | |
| Jun 12, 2014 at 12:26 | history | edited | Limbo Exile | CC BY-SA 3.0 |
Tried to make more clear that I am trying to catch a specific exception
|
| Jun 12, 2014 at 12:01 | comment | added | Marc van Leeuwen |
To all those who are saying: just throw (or let pass) an exception, you are making unfounded assumptions on how this code is being used. One possible scenario is that there is a problem to be solved, with various heuristic solution methods that solve ever bigger subclasses of the problem at ever increasing cost; it would make sense to write something like if (FirstMethodSucceeds(problem) or SecondMethodSucceeds(problem) or ...) Hurray(); else UniversalSolve(problem);. Doing the same with (custom?) exceptions would be uselessly more complicated.
|
|
| Jun 12, 2014 at 10:42 | answer | added | Jacek Prucia | timeline score: 0 | |
| Jun 12, 2014 at 5:41 | history | edited | Limbo Exile | CC BY-SA 3.0 |
Moving from the general problem to a more precise one.
|
| Jun 12, 2014 at 0:45 | comment | added | jpmc26 | As indicated by the large number of comments saying this is a Bad Idea™, it would probably be helpful if you gave some more details about why you need to do this. In general, this is rarely a good design. | |
| Jun 12, 2014 at 0:18 | answer | added | 000 | timeline score: 0 | |
| Jun 11, 2014 at 22:54 | comment | added | Bob Jarvis - Слава Україні |
Umm...BadlyDesignedMethodInSeriousNeedOfRefactoring? And to answer your question about the exceptions - I'd either let the caller handle them, or catch them and then throw a custom exception that means "this method no do its job". Share and enjoy.
|
|
| Jun 11, 2014 at 21:41 | answer | added | user136354 | timeline score: 1 | |
| Jun 11, 2014 at 19:14 | answer | added | Gergy008 | timeline score: 0 | |
| Jun 11, 2014 at 17:12 | comment | added | CodesInChaos | This kind of exception handler is rarely a good idea. Only catch specific exceptions you're expecting, not all of them. And if possible avoid throwing it in the first place, eliminating the need to catch it. | |
| Jun 11, 2014 at 16:23 | history | tweeted | twitter.com/#!/StackProgrammer/status/476761693172023297 | ||
| Jun 11, 2014 at 15:18 | comment | added | JAB | (The main usage for that would be interfacing with some other language that isn't as strictly typed as Java and relies heavily on, say, passing messages as strings for one reason or another.) | |
| Jun 11, 2014 at 15:16 | comment | added | JAB |
@maaartinus And how would you handle a situation where the exception only has meaning within the method itself, and externally you only care whether or not the procedure succeeded but not about the specifics (assuming the wrapped exceptions are specific to the procedure and not generalized)? For example, with Java reflection, there's no method that checks for the existence of a method on a class, only methods to retrieve a Method object or throw an exception when the requested method does not exist (you could retrieve the list of methods for the class and search that, but it's not one call).
|
|
| Jun 11, 2014 at 14:54 | comment | added | maaartinus |
Most of the time, I'd call it "broken" as returning a boolean instead of wrapping or passing the exception is nearly always wrong.
|
|
| Jun 11, 2014 at 12:18 | answer | added | amd | timeline score: 8 | |
| Jun 11, 2014 at 10:03 | answer | added | ne2dmar | timeline score: 70 | |
| Jun 11, 2014 at 9:59 | answer | added | mrjink | timeline score: 8 | |
| Jun 11, 2014 at 9:49 | comment | added | Benni | It depends on the usage of the function and the stuff that is being done. If it is necessary, that the stuff needs to be executed correctly, then I would consider this approach flawed, because the user of the function might miss the boolean flag and also lacks information provided by the exception. | |
| Jun 11, 2014 at 9:47 | answer | added | npinti | timeline score: 18 | |
| Jun 11, 2014 at 9:41 | history | asked | Limbo Exile | CC BY-SA 3.0 |