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

No thanks.

No thanks.

Posted Nov 11, 2012 15:29 UTC (Sun) by paulj (subscriber, #341)
In reply to: No thanks. by Cyberax
Parent article: Haley: We're doing an ARM64 OpenJDK port!

From my perspective, programming network services, where inputs may come from bad actors, and where the last you want to do is to allow a bad actor to cause your system to deny service to the good actors, I flatly disagree that violation of contracts should result in fatal errors - termination of that service to that actor, in a clean way, yes, fatal end of programme and all service: absolutely the wrong goal. (Invariants should be fatal, but that's a different thing).

And if you think I've been arguing that errors should be returned and caught and handled at each method call you've simply not read my comments, and you're just arguing with a figment of your own imagination. Good luck with that :).


(Log in to post comments)

No thanks.

Posted Nov 11, 2012 15:57 UTC (Sun) by raven667 (subscriber, #5198) [Link]

Fatal termination of the program might be the only safe bet if the internal state is compromised by a bad actor, I would be distrustful of claims to "cleanly" recover or try to "handle" errors that they actually can't handle. That's why long-running processes should be run under high availability supervision like daemontools or systemd.

I'm no expert on implementation details but the idea of Exceptions seems right to me, errors can't be ignored, they have to be handled or the program dies, which seems better to me than having your program jump the track and keep stupidly barreling along mowing through your data, driving through your living room window 8-)

No thanks.

Posted Nov 11, 2012 16:19 UTC (Sun) by paulj (subscriber, #341) [Link]

If the internal state is compromised yes. However, you want to reject the bad actor's input before that happens. Parsing things with state machines and related automata, and cleanly rejecting invalid input (and dispensing with associated state) is not rocket science. (Note that method calls related to some piece of state can be viewed as inputs/transitions on an automaton).

Asserting and crashing should be a last resort in daemons that must provide shared-state services to multiple actors. While it is preferable to assert than to allow a security critical error, asserting itself may be a security critical error - handling errors cleanly is again preferable to the assert. A better approach is to have multiple layers of defence, with asserts against critical inconsistency errors at lower layers (e.g. forcing all IO through checked, bounded buffer abstractions), and well-defined automata at higher layers to provide clean error semantics (potentially multiple levels of such). You can't just restart, because of the shared-state. If you externalise the shared-state so that the code can be restarted, you still need to ensure that shared-state can never be manipulated into an inconsistent state.

All the world is a state machine, even the functional programming world. ;)


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