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

No thanks.

No thanks.

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

Whether you do or don't use exceptions, it's far from a bad idea for objects to always check their internal consistency on entry from external callers. As for dealing with errors in clean up, remind me again how exceptions improves on that? Would you throw an error from a destructor?

Also, you seem to be suffering from some kind of binary thinking - that people are either for or against something - and projecting that onto others. I have not at any stage expressed an opinion on whether exceptions should be avoided or not.


(Log in to post comments)

No thanks.

Posted Nov 11, 2012 11:20 UTC (Sun) by Cyberax (✭ supporter ✭, #52523) [Link]

>Whether you do or don't use exceptions, it's far from a bad idea for objects to always check their internal consistency on entry from external callers.
That's a bad idea because of a several reasons. All reliable systems should be built on the idea of invariants and contracts. The violation of the contract/invariant should be treated as a fatal error.

So putting "assert(someInvariantState==43)" in method's body is fine as a purely debugging tool to find programmer's error. However, doing "if (someInvariantState!=42) return -ERR;" is a big NO-NO.

>As for dealing with errors in clean up, remind me again how exceptions improves on that? Would you throw an error from a destructor?
C++ doesn't have a nice solution for that. Java has one in the form of nested exceptions - it's possible to replace the current exception with the new one, retaining the current one as a nested exception.

No thanks.

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

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 :).

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