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

No thanks.

No thanks.

Posted Nov 9, 2012 10:22 UTC (Fri) by hummassa (subscriber, #307)
In reply to: No thanks. by paulj
Parent article: Haley: We're doing an ARM64 OpenJDK port!

That is the point:

> Sorry, but it's a fact that exceptions introduce implicit control-flow branch points at each statement, potentially even multiple such.

THAT IS NOT A FACT AT ALL.

Those implicit control-flow branch points WILL HAVE TO BE DEALT WITH ANYWAY, they were already there. Only without exceptions you have to deal with them all at all positions in your code. Explicitly. You are writing code that is scaffolding code, not code that does what the program actually needs to do.

When you use exception, you write only the code that does what the program actually needs to do, with some sanity checks here and there. You follow the sanity rules, you are safe.

For instance, every time you open a file things can go wrong. Supposing you have a function call hierarchy main -> f -> g -> h, and h() wants to open a file, one of the following will happen:

1. you (generic "you", ok?) won't check open() results, will proceed as if the file was open, and undefined and terrible things will happen;

2. (try#2) you will check open() results, return an error code, g() does not check for the error code and proceeds, hilarity ensues;

3. (yes it finally works) g() checks h() error code, f() checks g() error code, main() checks f() error code, prints a suitable message.

4. (despair happenning) you have to call i() from g() and j() from f() and both have to open files. At this point, if you don't forget anything (you have to do every of these checks yourself, manually) you have a program that is at least 25% scaffolding.

With exceptions, one of those will:

1. open() throws, _main() aborts and prints "unexpected exception". The program already works.

2. (let's make this pretty) you put a catch() block on main(), print a pretty message cerr << "file " << name << " could not be open". The program still works.

3. (down the road) you have to add i() and j() and the program still works. No need to repeat step 2.

> Note that I was not advocating for error return codes.

No, but you are differentiating "implicit control-branch points" from "explicit" ones and it does give that impression. My point is that: implicit control-branch points are there anyway (you open a file, things can go wrong in the process), and dealing with them implicitly is better then explicitly.

Yes, dealing implicitly with exceptions means that sometimes you have to be exceptionally (ha!) safer (constructors/destuctors). But it just helps you to clarify your code and tell better when things can go wrong.


(Log in to post comments)

No thanks.

Posted Nov 9, 2012 10:29 UTC (Fri) by paulj (subscriber, #341) [Link]

So the control-flow branch points which you disagree exist have to be dealt with anyway? So they don't exist but they do.

There are other ways to deal with errors, besides exceptions or error return codes. You can design the underlying, called-into code to explicitly follow a state machine, and have idempotent error state. Calling code then do a number of operations on such objects, and check at the end whether they succeeded or not, and if not, query the reason for the error.

No thanks.

Posted Nov 9, 2012 16:35 UTC (Fri) by HelloWorld (guest, #56129) [Link]

> So the control-flow branch points which you disagree exist
Did you even read what he wrote? He didn't say they don't exist, he said that they exist regardless of whether you use exceptions or error codes to handle errors.


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