| |||||||||||||
No thanks.No thanks.Posted Nov 11, 2012 12:36 UTC (Sun) by paulj (subscriber, #341)In reply to: No thanks. by hummassa Parent article: Haley: We're doing an ARM64 OpenJDK port!
Pretty much all non-trivial objects (composites, or ones with implicit constraints on fields that can't be expressed in the type system or language) have an FSM, at a minimum the 2-state FSM of "Internal state is consistent" and "Internal state is not consistent". You have to deal with that reality one way or another. Tracking that consistency internally through an explicit FSM is one way. Dealing with invalid use of that object after errors through an idempotent error state or assertions or exceptions all have their pros and cons.
You don't have to synchronise all the FSMs. Or at least, if you do, then it wasn't because you added an explicit FSM - you had to effectively be synchronising their state already anyway. All it does is crystalise and making explicit (inc making it queryable to outside users) requirements that are already there.
(Log in to post comments)
No thanks. Posted Nov 11, 2012 13:06 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]
That's about THE WORST possible system to write software. It combines everything:
1) Hidden state, affecting execution silently. 2) Completely decoupling the error site and the place where error is detected/handled. 3) Possible unforseen interactions through side-effects. 4) Mutable objects. 5) Non-thread safety by design.
No thanks. Posted Nov 11, 2012 15:07 UTC (Sun) by paulj (subscriber, #341) [Link]
1. Many state+code objects in software have hidden state - it's called encapsulation.
2. Decoupling error handling from the error site (in terms of the programming language syntax) is exactly what exceptions do!
3. You could level this argument at pretty much any OOP code, you'd have to be writing pure functional code to avoid this charge.
4. Ditto.
5. Thread safety is completely orthogonal. Making it thread-safe is no different to making other stateful objects thread safe.
You're just throwing accusations blindly in the hope some stick, methinks. :)
No thanks. Posted Nov 12, 2012 1:52 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]
>1. Many state+code objects in software have hidden state - it's called encapsulation.
Normal designers try to MINIMIZE it. You are not only add it gratuitously, but also introduce non-trivial interdependencies between objects.
For instance:
What if j.jiggle() takes 10 minutes to complete? Then your code would just be losing time if "f.twiddle()" is in error.
>2. Decoupling error handling from the error site (in terms of the programming language syntax) is exactly what exceptions do!
Not error handling, but error _detection_. You can simply forget to check that f's state is OK after the loop. Then there's a problem with compounded errors.
> 3. You could level this argument at pretty much any OOP code, you'd have to be writing pure functional code to avoid this charge.
Nope. Good modern OOP code tries to minimize mutability (it's OK to use mutable objects where it's necessary) - a lot of new OOP languages even have variables that are immutable by default, for example.
> 5. Thread safety is completely orthogonal. Making it thread-safe is no different to making other stateful objects thread safe.
No. For instance "f" object might be immutable except for its "error" state.
BTW, I think that there should definitely be a death penalty for those who abuse do..while loops to emulate "goto".
No thanks. Posted Nov 12, 2012 10:05 UTC (Mon) by paulj (subscriber, #341) [Link]
No dependencies have been added between objects.
In extreme cases, such as j.jiggle () taking 10 minutes, then you might want to check before it. I gave a sketch of a programming pattern - it wasn't intended to be an exact solution for every possible programming problem. If you use it, you will still need to apply some intelligence of your own.
Note further, I was not even claiming that this is *THE* pattern to solve all error-handling. I was just giving it as an example, for consideration, as you earlier had asked for examples of error handling without exceptions (well, you asked for a goto error-exit pattern example, but I assumed other examples would also be allowed).
Object mutability: If an object is immutable, then its state doesn't change and will be immutable. Clearly there is little point in applying state-tracking patterns to single-state objects. This pattern applies to objects with a finite multiplicity of states. Despite your contention, I am fairly sure programming is full of such objects.
Even if you use a series of immutable objects and transition between them, you will still have an FSM with mutable state at a level above those immutable objects, implicitly or explicitly.
|
|||||||||||||