I guess you could call this an OOPsie
😆
Nice
I misread Exceptioncatcher as Exceptionhatcher and I think it still fits
I believe the lifecycle goes ExceptionLayer, ExceptionIncubator, ExceptionHatcher
It's critical you don't throw your exceptions too early, they need to learn to fly first 🤣
I thought that's why you throw them?
Repeat after me:
public static void main(String[] args)blasphemy!
void main(int argc, char ** argv, char ** envp)public static void main(String[] args) public static void main(String[] args) public static void main(String[] args)Am I summoning the flying spaghetti monster?
The object man appears behind you while you're coding and inserts a null reference that takes you a day to find.
I'm sorry, but the only spaghetti you get is a 17 levels deep
ifclause.
We have been played for absolute fools
and like a goddamn fiddle!
functional programming ftw
Functional Programming Theory: 500 pages of lambda calculus and endofunctors
Functional Programming Practice: Quicksort
There's plenty of real world code written in functional languages. Also, this idea that FP is somehow more complex is complete nonsense. Lisp family are some of the easiest languages to learn.
You can't spell "functional programming" without "fun".
Functional programming is perfect for all my projects that I don't start!
Been working in Clojure for over a decade now, and would never never go back to using imperative/OOP at this point.
TBH Rust is pretty nice, it borrows (pun intended) a lot of ideas from the functional world (algebraic data types, traits, closures, affine types to an extent, composition over inheritance, and the general vibe of type-driven development), but it's much easier to write fast, efficient code, integrate with decades of libraries in imperative languages, and the ecosystem somehow feels mature already.
Would you make a game with functional programming? Or anything with a GUI?
Needs a
FactoryFactoryI'm just a hobbyist but...are you guys using exceptions like they're conditional statements?? I thought those were for only when shit is seriously wrong and execution can't continue in the current state. Like if some resource was in a bad state or some input was malformed.
Or maybe I haven't worked on anything complex enough, I dunno.
I thought those were for only when shit is seriously wrong and execution can't continue in the current state.
That's how it starts. Nice and simple. Everyone understands.
Until
some resource was in a bad state
and you decide you want to recover from that situation, but you don't want to refactor all your code.
Suddenly, catching exceptions and rerunning seems like a good idea. With that normalized, you wonder what else you can recover from.
Then you head down the rabbit hole of recovering from different things at different times with different types of exception.
Then it turns into confusing flow control.
The whole Result<ReturnValue,Error> thing from Rust is a nice alternative.
As a rule, exceptions should indeed be used for behaviors that are outside normal execution flow. For example, you might throw an exception if a file you're trying to access doesn't exist, or a network call fails, etc.
I suppose it depends on the language? For the most part I think you're right. Exceptions are only used (if at all) in situations where a program diverges unexpectedly from its normal flow. But take a language like Python. They're just everywhere. Even your plain old
forloop ends on an exception, and that's just business as usual.Python programmers appear to actively promote the 'easier to ask forgiveness, than permission' style nowadays. This article has a measured take: https://realpython.com/python-lbyl-vs-eafp/
You don't want to use exceptions in normal control flow, because they're extremely slow. Every time you
throwan exception, it has to collect a stacktrace, which is hundreds, if not thousands, of calculations, compared to a handful of calculations for returning a boolean or an enum variant.
Feeling attacked with
LeggableandFleable. I’ve been known to write a concern or two in Ruby on Rails but what can I say? I like my code DRY.My biggest problem with it is that those aren't verbs. You might have
LegCount -> CountableandFleaCount -> Countablethough.Yeah, that’s pretty annoying.
I straight up never got a nice answer from StackOverflow on this. Say you have 5 classes, each requiring access to the data members/functions of the others. What's a nice way to solve this problem? I've thought of only two
niceshit methods:- Pass pointers/shared-pointers etc to each class, but not through the constructor but a setter function
- Pass lambdas or std::function everywhere. Yuck! Still doesn't put each object in a valid state in the constructor.
Well, what problems are you trying to solve by having the classes all access each other's data members? Why is that necessary?
The. real question is whether this problem needs to be modelled using classes in the first place. The alternative is to just have a set of composable functions that take a piece of data and return a modified version that can be passed to a different function.
