User: Password:
|
|
Subscribe / Log in / New account

No thanks.

No thanks.

Posted Nov 12, 2012 1:52 UTC (Mon) by Cyberax (✭ supporter ✭, #52523)
In reply to: No thanks. by paulj
Parent article: Haley: We're doing an ARM64 OpenJDK port!

>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:
>f.twiddle();
>j.jiggle();

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".


(Log in to post comments)

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.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds