Timeline for Is "avoid extra null pointer risk" a reason to avoid "introduce parameter objects"?
Current License: CC BY-SA 4.0
28 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 4, 2024 at 6:28 | comment | added | Sebastian Redl | If we're talking unrelated problems, "some error dialog" is not an appropriate error handling strategy in a random non-UI function on a null pointer condition. | |
| S Jul 31, 2024 at 11:07 | history | suggested | CommunityBot | CC BY-SA 4.0 |
fixed grammar
|
| Jul 24, 2024 at 19:13 | comment | added | gnasher729 | @Polygnome One problem at a time. | |
| Jul 24, 2024 at 18:30 | comment | added | David Conrad |
ShowScheduleParameters is a terrible name. What about DateRange?
|
|
| Jul 23, 2024 at 13:09 | answer | added | Peter - Reinstate Monica | timeline score: 1 | |
| Jul 23, 2024 at 10:48 | comment | added | Polygnome | Why are you passing longs instead of Dates in the first place? Thats already fraught with problems. And when using dates -- well, you need to take care of null anyways. | |
| Jul 23, 2024 at 7:15 | answer | added | Ben | timeline score: 1 | |
| Jul 23, 2024 at 5:01 | history | protected | gnat | ||
| Jul 22, 2024 at 19:25 | comment | added | gnasher729 | @prosfilaes I once used a C++ library that had a constructor for point objects with values x, y. Then some genius changed it to v(ertically) And h(orizontally). Every single call to the constructor was wrong with no chance for the compiler to tell you. | |
| Jul 22, 2024 at 16:08 | answer | added | user448595 | timeline score: 0 | |
| Jul 22, 2024 at 16:06 | comment | added | gidds | This depends very much upon the language. Neither this question nor the linked question specify a language, but I guess they may be about Java, in which case it's probably a valid concern. However, it's NOT a concern in a language with non-nullable types, such as Kotlin — there, the compiler will prevent null being passed to a param of a non-nullable type, whether directly or indirectly. (In such cases, not only is a null check completely unnecessary, but the compiler will flag it up as such!) | |
| Jul 22, 2024 at 15:57 | review | Suggested edits | |||
| S Jul 31, 2024 at 11:07 | |||||
| Jul 22, 2024 at 14:59 | answer | added | prosfilaes | timeline score: 1 | |
| Jul 22, 2024 at 14:55 | comment | added | prosfilaes | @gnasher729 In this case, I'd be surprised if start, end got passed in the wrong order, and and it's easy to check inside the function. | |
| Jul 22, 2024 at 14:15 | answer | added | candied_orange | timeline score: 21 | |
| Jul 22, 2024 at 12:51 | comment | added | gnasher729 | @Flater And it is many times easier to pass two parameters in the wrong order than passing NULL instead of an object. In the second case, the error is obvious on the most superficial glance. | |
| Jul 22, 2024 at 12:34 | history | became hot network question | |||
| Jul 22, 2024 at 7:13 | comment | added | gnasher729 | Basically, don’t base your code design on the assumption that your coworkers might be useless numpties. | |
| Jul 22, 2024 at 6:35 | review | Close votes | |||
| Jul 27, 2024 at 3:06 | |||||
| Jul 22, 2024 at 6:21 | comment | added | Flater | "I may pass null to showSchedule accidentally, which the original version never happens this." If you omitted a non-nullable parameter, your code still would not have worked (otherwise this parameter would be pointless in the first place). You also don't forget to pass in null, you actively pass it in. If you don't trust yourself to not pass in a null, why would you trust yourself to pass in the correct parameter value even if null weren't an option? This question seems based on a half-baked idea that you haven't fully explored to understand what problem you're actually trying to prevent. | |
| Jul 22, 2024 at 6:03 | answer | added | gnasher729 | timeline score: 12 | |
| Jul 22, 2024 at 5:29 | answer | added | user448541 | timeline score: 0 | |
| Jul 22, 2024 at 5:19 | history | edited | wcminipgasker2023 | CC BY-SA 4.0 |
added 6 characters in body
|
| Jul 22, 2024 at 5:13 | history | edited | wcminipgasker2023 | CC BY-SA 4.0 |
added 479 characters in body
|
| Jul 22, 2024 at 5:06 | answer | added | Doc Brown | timeline score: 26 | |
| Jul 22, 2024 at 4:30 | comment | added | Doc Brown | Blindly grouping parameters does not improve readability. Come up with a better name, ShowScheduleParameters is horrible, it shows you did not read the linked Q&A with its comments properly, especially the first comment under the accepted answer. | |
| Jul 22, 2024 at 4:13 | comment | added | Flater | The underlying assertion of this question seems to be that we should avoid reference types on the implied inevitability of causing null issues by doing so, as opposed to advocating for proper null handling when using a reference type. Is there a source for this implication, or is this an interpretation on your part? | |
| Jul 22, 2024 at 3:56 | history | asked | wcminipgasker2023 | CC BY-SA 4.0 |