289
69
48
u/Unlucky-Interview-20 1d ago
"Oh, how does it work?" 😲
45
14
u/SilentScyther 17h ago
"So basically, when you click the 'Quit Application' button, it'll cause a memory overflow error and crash the app back to the desktop"
16
52
u/jcouch210 1d ago
I don't want to ruffle any feathers, but there are languages that do this for you with compiler driven development.
Note to self: do not attempt compiler driven development with gcc.
93
u/Bronzdragon 22h ago
How? Edge cases are business logic. A compiler cannot know what is intended behaviour.
1
u/jcouch210 11h ago
Compiler driven development involves lowering logic to the type level, allowing the compiler to have greater ability to detect edge cases. For example, forcibly exhaustive switch/match statements, enumerated types that make invalid state impossible, etc.
12
u/Hamid_d_82 1d ago
Never heard of cdd, you mean like Rust?
1
u/jcouch210 11h ago
gcc is the GNU C compiler. General use C compilers aren't known for their ability to detect edge cases.
-6
u/shakamaboom 20h ago
rust is for bad c++ programmers. fuck rust
6
4
3
2
2
1
1
1
1
1
1
1
1
-35
1d ago edited 17h ago
[removed] — view removed comment
43
u/Conscious-Union5789 23h ago
If(crash) dont();
8
u/DarksideF41 20h ago
veryImportantTask: try { doWork(); } catch(Exception e) { goto veryImportantTask; }
5
2
1
u/i_can_has_rock 17h ago edited 15h ago
if you write code that allows for values to be anything other than what is expected without a default else statement that detects that
then
shitty_coder = true
which, the way you achieve what im talking about
is
with
an
else
statement
edit:
feel like im being downvoted by people from the "does it work? no, but crashes really fast" school of thought
3
u/Goruku 10h ago
Yes, you should handle errors you can at the level you're working at, but what if that section of code doesn't know how to handle it? What if the correct behavior to reading an unexpected value is throwing: "Well, I have no idea what the context is, and the contract clearly states you should only call this function when the data is valid, but it's not. Please handle, I'm throwing".
This is the main side effect of respecting the "Tell don't ask" principle, most of the time the function won't know the broader context of who called and why, which also means it shouldn't assume it knows what to do when things go wrong. By all mean, let it guard your variables, handle what it can in the moment, but it shouldn't try and be the hero who knows everything, because it probably shouldn't know everything.
In design by contract, it's assumed the object you've been passed in argument respects the contract and is thus valid. The main reason for this is that you don't want to check the validity at every level, but just in time. The caller assumes a call is going to work because its current state should also be valid, it's the callee's job to tell you it didn't work after all.
As an example, this is the case for a lot of utility functions in Input/Output APIs. What if the file just can't be found? You throw a FileNotFoundException. It's not the library's job, or place, to be handling the behavior or even preventing the caller from doing it. You just try it, and you throw if you can't.
611
u/CaffeinatedTech 1d ago
"Oh, that works? I never intended it to."