5 ms·

Assertions, throws, and try-catch are code smells. Really bad design choice considering we have more elegant solutions like monads.

TeMPOraL 8y ago
Assertions, yes, in so far as they mean "I know this can't happen, but I can't structurally prevent it in the program in an elegant fashion, with the tools I use". However, I can't see how monads are suddenly going to make this problem disappear. As for throws/try-catch - beyond assertion use, they also report all problems that are outside your control (like IO failing due to HDD damage, or connection dropping). Those kinds of problems are here to stay.
oftenwrong 8y ago
Sure, monads provide an elegant way to structure code with error conditions, but I don't see a problem with using simple assertions, throws, try-catch to enforce invariants. Personally, I don't care about elegance as much as whether or not it works, as long as it is simple to use and maintain. I can return something like a Maybe/Either, or I can throw an exception - both approaches are fine by me if it forces the programmer to account for error cases.
- pmichalina 8y ago
  Throwing is a side effect breaking flow of control for no good reason. It’s takes you down the same path as all other spaghetti code. Not as much elegance as it is about purity. Minimizing side effects is the number one way to reduce bugs. It should be the number one guiding principle when creating out reliable software. Which means, you simply cannot use the primitive try catch or similar construct. Don’t break flow of control. Guide it to a terminal value instead. These days, when I see try-catch and if-else constructs (which is in most codebases) it’s clear there will be bugs over the life of the application. It’s fine, use them, but there is a world of greatness when you ditch these faulty constructs. Just like ditching OOP constructs. All built on false premises.
  - platinumrad 8y ago
    This is what happens when you read just one chapter of Learn You a Haskell kids. Monads, not even once.
  - carapace 8y ago
    You're correct, but you are arguing with fools. If they could understand what you're saying they would already. A few of them will get there eventually but software development will be a tire-fire, a cornucopia of bugs, for a while yet to come I think.
    - platinumrad 8y ago
      Nobody here is saying that monadic error handling isn't good (in case it wasn't abundantly clear, my comment was this thing that people call a "joke"). The issue is pmichalina flippantly disparaging asserts, one of the few good things left in this hell world: https://www.microsoft.com/en-us/research/publication/assessing-the-relationship-between-software-assertions-and-code-qualityan-empirical-investigation/ https://www.microsoft.com/en-us/research/publication/assessi...
      - carapace 8y ago
        It wasn't abundantly clear, but I'm often humorless. Sorry for being so crusty. I just found out that about a third of my professional career was essentially waste because I was too thick to adopt Prolog twenty years ago. It almost physically hurts to think about it. Anyway, I think OP's right about assertions being a code smell: an assertion is literally the place where you tell the machine you don't know exactly what you're doing, eh? I've been working towards an error-free mode of development, a combination of Dr. Margaret Hamilton's "Higher Order Software" concept that developed out of the Apollo 11 project with mathematical derivation of programs. I'm just about ready to "productize" it but I'm not going to market it to other developers. I'm going to sell it directly to consumers. They won't know enough to argue with the method, they'll just be able to use the computer to solve problems, I won't tell them that they are programmers. Bottom line: error-free software development methods have been available for decades but the industry tends to ignore them. In 2018 writing "assert", "throw" or "raise", etc. is a code smell: you are doing it worng. If I sound cranky it's because I am.
shidoshi 8y ago
pp. 76-77 of Ousterhout's "A Philosophy of Software Design" talk about the issues with boilerplate try-catch. He basically does not approve, as they make readability suffer and often do not do what they advertise (truly catch errors.) I don't know how he would feel about production assertions, but I'm guessing he would buy into it if it helps reduce complexity. In the sense of finding remedies to troublesome bugs--which will occur.
js8 8y ago
There are three main ways to reduce errors in code: tests, asserts and abstractions. All three have advantages and disadvantages and generally deal with different classes of errors. In this thread, we discuss asserts, not abstractions. Monad is an abstraction. (On the other hand, many people only see tests and forget about two other solutions, which are as important.)
- pmichalina 8y ago
  Tests are good of course, but that assumes the tests are valid. I’d rather trust compiler to ensure runtime safety.
swatcoder 8y ago
This kind of absolutism only works in the lab and the journal. The real world of software engineering is enormously varied and each project faces a different set of legitimate constraints and objectives. It's more valuable to discuss how and when to use "assertions, throws, and try-catch[es]" than to pretend that they're universally superceded by some other construct.
vmchale 8y ago
Well, in languages released in the past 15 years, sure. But many languages are not that recent.

TeMPOraL 8y ago

Assertions, yes, in so far as they mean "I know this can't happen, but I can't structurally prevent it in the program in an elegant fashion, with the tools I use". However, I can't see how monads are suddenly going to make this problem disappear. As for throws/try-catch - beyond assertion use, they also report all problems that are outside your control (like IO failing due to HDD damage, or connection dropping). Those kinds of problems are here to stay.

oftenwrong 8y ago

Sure, monads provide an elegant way to structure code with error conditions, but I don't see a problem with using simple assertions, throws, try-catch to enforce invariants. Personally, I don't care about elegance as much as whether or not it works, as long as it is simple to use and maintain. I can return something like a Maybe/Either, or I can throw an exception - both approaches are fine by me if it forces the programmer to account for error cases.

pmichalina 8y ago
Throwing is a side effect breaking flow of control for no good reason. It’s takes you down the same path as all other spaghetti code. Not as much elegance as it is about purity. Minimizing side effects is the number one way to reduce bugs. It should be the number one guiding principle when creating out reliable software. Which means, you simply cannot use the primitive try catch or similar construct. Don’t break flow of control. Guide it to a terminal value instead. These days, when I see try-catch and if-else constructs (which is in most codebases) it’s clear there will be bugs over the life of the application. It’s fine, use them, but there is a world of greatness when you ditch these faulty constructs. Just like ditching OOP constructs. All built on false premises.
- platinumrad 8y ago
  This is what happens when you read just one chapter of Learn You a Haskell kids. Monads, not even once.
- carapace 8y ago
  You're correct, but you are arguing with fools. If they could understand what you're saying they would already. A few of them will get there eventually but software development will be a tire-fire, a cornucopia of bugs, for a while yet to come I think.
  - platinumrad 8y ago
    Nobody here is saying that monadic error handling isn't good (in case it wasn't abundantly clear, my comment was this thing that people call a "joke"). The issue is pmichalina flippantly disparaging asserts, one of the few good things left in this hell world: https://www.microsoft.com/en-us/research/publication/assessing-the-relationship-between-software-assertions-and-code-qualityan-empirical-investigation/ https://www.microsoft.com/en-us/research/publication/assessi...
    - carapace 8y ago
      It wasn't abundantly clear, but I'm often humorless. Sorry for being so crusty. I just found out that about a third of my professional career was essentially waste because I was too thick to adopt Prolog twenty years ago. It almost physically hurts to think about it. Anyway, I think OP's right about assertions being a code smell: an assertion is literally the place where you tell the machine you don't know exactly what you're doing, eh? I've been working towards an error-free mode of development, a combination of Dr. Margaret Hamilton's "Higher Order Software" concept that developed out of the Apollo 11 project with mathematical derivation of programs. I'm just about ready to "productize" it but I'm not going to market it to other developers. I'm going to sell it directly to consumers. They won't know enough to argue with the method, they'll just be able to use the computer to solve problems, I won't tell them that they are programmers. Bottom line: error-free software development methods have been available for decades but the industry tends to ignore them. In 2018 writing "assert", "throw" or "raise", etc. is a code smell: you are doing it worng. If I sound cranky it's because I am.

shidoshi 8y ago

pp. 76-77 of Ousterhout's "A Philosophy of Software Design" talk about the issues with boilerplate try-catch. He basically does not approve, as they make readability suffer and often do not do what they advertise (truly catch errors.) I don't know how he would feel about production assertions, but I'm guessing he would buy into it if it helps reduce complexity. In the sense of finding remedies to troublesome bugs--which will occur.

js8 8y ago

There are three main ways to reduce errors in code: tests, asserts and abstractions. All three have advantages and disadvantages and generally deal with different classes of errors. In this thread, we discuss asserts, not abstractions. Monad is an abstraction. (On the other hand, many people only see tests and forget about two other solutions, which are as important.)

pmichalina 8y ago
Tests are good of course, but that assumes the tests are valid. I’d rather trust compiler to ensure runtime safety.

swatcoder 8y ago

This kind of absolutism only works in the lab and the journal. The real world of software engineering is enormously varied and each project faces a different set of legitimate constraints and objectives. It's more valuable to discuss how and when to use "assertions, throws, and try-catch[es]" than to pretend that they're universally superceded by some other construct.

vmchale 8y ago

Well, in languages released in the past 15 years, sure. But many languages are not that recent.