4 ms·

I've solved n-queens once before using exceptions to handle control flow. I coded a recursive solution for an assignment, but I wrote it wrong and it ended up p

by jjmarr 2y ago

I've solved n-queens once before using exceptions to handle control flow. I coded a recursive solution for an assignment, but I wrote it wrong and it ended up printing all of the possible solutions instead of just one. Because I didn't have much time before the final submission, I just put the initial call in a try catch block and threw an exception to indicate successful completion.

actionfromafar 2y ago
Enterprise ready. :)
CJefferson 2y ago
Honestly, this is the best way to write recursive algorithms in my opinion (and I write a lot of recursive search algorithms in my research). The alternative is every single function has to return a boolean, along with whatever else it would return, which is true when you have found a solution, and you then return straight away -- effectively just reimplementing exceptions by hand, which doesn't feel like a useful use of my time.
- kamaal 2y ago
  Its strange that its 2025 and we haven't compiled recursion as a design pattern with rules, like a framework, using which all problems that can be solved by recursion can be represented.
- rollcat 2y ago
  Sounds like Go to me! Every single function that can fail has to return an error value, which is nil if you have succeeded. I love Go, but its error handling leaves so much to be desired. I even have an Emacs macro that inserts "if err != nil" for me. Also very easy to make a mistake in the rare case where you have to write "if err == nil"; my eyes just skip over any line that includes the words "if", "err", and "nil", as if it was some attention-hungry inline ad. Rust started off chatty, but soon introduced the "?" syntax, which works perfectly well in the 99% case. Go had a couple of similar proposals, but "keep if err != nil" just... won.
  - 9rx 2y ago
    > which works perfectly well in the 99% case. Not without its related traits and whatnot. Without those you have the same all the same problems the Go proposals keep running into. Trouble is that it is not yet clear what the Go equivalent is to those related features. However, the attempts to figure that out keep coming. Ian Lance Taylor (of generics fame) recently implemented the latest proposal to try it out, although it seems it too has failed, but suggests that things are inching closer to something usable when the initial details were able stand up to basic scrutiny. Nothing has "won" yet.
  - stouset 2y ago
    I remember when Rob Pike wrote an essay insisting that `if err != nil` isn’t all that common and golang programmers clearly would wrap that logic in more fluid interfaces which would prevent the redundant boilerplate.
    - DangitBobby 2y ago
      https://go.dev/blog/errors-are-values https://go.dev/blog/errors-are-values
      - the_gipsy 2y ago
        This reads like satire!
        stouset 2y ago
        I’ll be honest, having been involved off and on with golang over 10+ years, I constantly feel like I’m being gaslit. It’s fine that golang has made missteps along the way and course corrects. Or if people realize that some hoped-for development doesn’t come to pass, but the current state of things is acceptable. But the number of times it feels like we’re just told things were always this way, or this was always the goal, or actually having 2/3s of the language being redundant boilerplate is a good thing (it’s “explicit”), or actually they always intended to have generics because it’s important for library authors, or actually systems programming always meant small network services, or actually abstraction is bad unless it’s coincidentally the exact level of abstraction that golang ended up with, or… on and on and on. It’s exhausting and it’s not a good look on the community.
- kccqzy 2y ago
  That's why in Haskell after the Either monad becomes popular, people simply made a library that flips the arguments to become the Success monad. The problem with most languages here is the name "exceptions" implying it's for exceptional scenarios, but without any substitute for good non-local control flow.
  - layer8 2y ago
    It’s not necessarily only for exceptional scenarios, but instead it is an exception to the normal return of a value. The usage where the return is always by exception (as in the n-queens example) is itself an exception ;). I do think it’s useful to mark one (return) type as the primary/normal/good case and other types as secondary/auxiliary/error cases, and have the latter auto-escalate independently.
- tcfhgj 2y ago
  "The alternative is every single function has to return a boolean" Rust: Return Some(value) or None
  - CJefferson 2y ago
    I tried that, the problem was some functions wanted to return an Option, then you end up with Option<Option<T>>, which is technically fine, but I find a bit mind bending.
- vbezhenar 2y ago
  Another alternative is setjmp/longjmp.

by jjmarr 2y ago

actionfromafar 2y ago

Enterprise ready. :)

CJefferson 2y ago

Honestly, this is the best way to write recursive algorithms in my opinion (and I write a lot of recursive search algorithms in my research). The alternative is every single function has to return a boolean, along with whatever else it would return, which is true when you have found a solution, and you then return straight away -- effectively just reimplementing exceptions by hand, which doesn't feel like a useful use of my time.

kamaal 2y ago
Its strange that its 2025 and we haven't compiled recursion as a design pattern with rules, like a framework, using which all problems that can be solved by recursion can be represented.
rollcat 2y ago
Sounds like Go to me! Every single function that can fail has to return an error value, which is nil if you have succeeded. I love Go, but its error handling leaves so much to be desired. I even have an Emacs macro that inserts "if err != nil" for me. Also very easy to make a mistake in the rare case where you have to write "if err == nil"; my eyes just skip over any line that includes the words "if", "err", and "nil", as if it was some attention-hungry inline ad. Rust started off chatty, but soon introduced the "?" syntax, which works perfectly well in the 99% case. Go had a couple of similar proposals, but "keep if err != nil" just... won.
- 9rx 2y ago
  > which works perfectly well in the 99% case. Not without its related traits and whatnot. Without those you have the same all the same problems the Go proposals keep running into. Trouble is that it is not yet clear what the Go equivalent is to those related features. However, the attempts to figure that out keep coming. Ian Lance Taylor (of generics fame) recently implemented the latest proposal to try it out, although it seems it too has failed, but suggests that things are inching closer to something usable when the initial details were able stand up to basic scrutiny. Nothing has "won" yet.
- stouset 2y ago
  I remember when Rob Pike wrote an essay insisting that `if err != nil` isn’t all that common and golang programmers clearly would wrap that logic in more fluid interfaces which would prevent the redundant boilerplate.
  - DangitBobby 2y ago
    https://go.dev/blog/errors-are-values https://go.dev/blog/errors-are-values
    - the_gipsy 2y ago
      This reads like satire!
      - stouset 2y ago
        I’ll be honest, having been involved off and on with golang over 10+ years, I constantly feel like I’m being gaslit. It’s fine that golang has made missteps along the way and course corrects. Or if people realize that some hoped-for development doesn’t come to pass, but the current state of things is acceptable. But the number of times it feels like we’re just told things were always this way, or this was always the goal, or actually having 2/3s of the language being redundant boilerplate is a good thing (it’s “explicit”), or actually they always intended to have generics because it’s important for library authors, or actually systems programming always meant small network services, or actually abstraction is bad unless it’s coincidentally the exact level of abstraction that golang ended up with, or… on and on and on. It’s exhausting and it’s not a good look on the community.
kccqzy 2y ago
That's why in Haskell after the Either monad becomes popular, people simply made a library that flips the arguments to become the Success monad. The problem with most languages here is the name "exceptions" implying it's for exceptional scenarios, but without any substitute for good non-local control flow.
- layer8 2y ago
  It’s not necessarily only for exceptional scenarios, but instead it is an exception to the normal return of a value. The usage where the return is always by exception (as in the n-queens example) is itself an exception ;). I do think it’s useful to mark one (return) type as the primary/normal/good case and other types as secondary/auxiliary/error cases, and have the latter auto-escalate independently.
tcfhgj 2y ago
"The alternative is every single function has to return a boolean" Rust: Return Some(value) or None
- CJefferson 2y ago
  I tried that, the problem was some functions wanted to return an Option, then you end up with Option<Option<T>>, which is technically fine, but I find a bit mind bending.
vbezhenar 2y ago
Another alternative is setjmp/longjmp.