Parsing JSON is a Minefield

Re:Parsing JSON is a Minefield by nradov on Wednesday October 26, 2016 @06:03PM (#12801078)

But exception handling is flow control, by its very nature. So it's clearly a gray area and the right thing to do depends on the common idioms of the language you're using, the expected frequency of parsing failures, and (possibly) runtime performance concerns. In Java for example, the XML parser built into the standard library does throw exceptions for certain types of invalid input.

[ Parent | on HN ]

Re:Parsing JSON is a Minefield by clock_tower on Wednesday October 26, 2016 @08:50PM (#12802075)

But see Djikstra on "GOTO statement considered harmful" (http://david.tribble.com/text/goto.html). The problem is unstructured control flow, which both GOTOs and exceptions-as-control-flow give you; at least in what I was taught (early-2000s CS degree focused on C++), unstructured flow of control is only acceptable when it's a panic button to quit the program (or a major area of processing).

It sounds like the Web way of doing things doesn't have this tradition -- much like how it doesn't have static strict extensible type systems.

[ Parent | on HN ]

Re:Parsing JSON is a Minefield by jholman on Thursday October 27, 2016 @01:35AM (#12803127)

Thank you for that great link. Thank you twice over, because it refutes your claim.

Dijkstra specifically calls out exceptions as structured control flow, and as being probably-acceptable, and not subject to his concerns.

More broadly, any argument that goes "Exceptions are an extension of GOTO, and therefore bad" has some questions to answer, given that nearly all control structures are implemented as an extension of GOTO.

As to your last sentence, I think you have it backwards. I speculate that of the code written in 2016, most of the code that did not use exceptions for control flow was Javascript async code. (There are of course other non-exception-using languages, but other than C they're mostly pretty fringe, and for good or for ill JS is so damn fecund).

[ Parent | on HN ]

Re:Parsing JSON is a Minefield by mypalmike on Thursday October 27, 2016 @06:19PM (#12810812)

> nearly all control structures are implemented as an extension of GOTO

Well put. Under the hood, every IF, ELSE, WHILE, SWITCH, FOR, and other decision point in structured code is implemented with at least one unconditional JMP.

[ Parent | on HN ]

Re:Parsing JSON is a Minefield by umbrai_nation on Wednesday October 26, 2016 @09:57PM (#12802356)

Exception flow control is far more structured than goto. An unexpected goto can drop you anywhere in memory, with no idea how you go there or how to get back. Exceptions cause a clearly-defined chain of events and you always know exactly where you'll end up (passing through all the finally blocks until you hit the closest catch block).

[ Parent | on HN ]

Re:Parsing JSON is a Minefield by inimino on Wednesday October 26, 2016 @10:05PM (#12802396)

It isn't unstructured. It is an exception from the control flow of calling and returning from functions, but it has a structure of its own which is often very convenient for writing clean code. This is not at all specific to the Web, by the way.

[ Parent | on HN ]

Re:Parsing JSON is a Minefield by ethbro on Wednesday October 26, 2016 @09:12PM (#12802165)

Quoting Dijkstra from 1968 on goto as argumentum ad authority in 2016 should be considered harmful.

He had reasons for saying what he said in the context of the times. Remove that temporal context and the why becomes more important than the what.

[ Parent | on HN ]

Re:Parsing JSON is a Minefield by clock_tower on Wednesday October 26, 2016 @09:37PM (#12802266)

His arguments are still sound, I think, and until that post I'd assumed that avoiding unstructured flow of control was still received wisdom. (I've certainly found it a very sound policy; million-plus-line codebases of other people's code, plus surprises, equal misery.)

Joel Spolsky had much the same to say: http://www.joelonsoftware.com/items/2003/10/13.html . If I'm going to have to argue about this, I'd rather use Spolsky than Dijkstra as a starting point; what, if anything, do you see that's wrong in his article?

[ Parent | on HN ]

Re:Parsing JSON is a Minefield by tblair on Wednesday October 26, 2016 @11:42PM (#12802760)

The article basically makes 2 points, which are:

1. They are invisible in the source code

2. They create too many possible exit points

As a java developer I really don't find 1 to be a problem at all. Lots of people complain about checked exceptions, but they solve this problem. It's very easy to see which functions throw and which don't. I'd even argue that the invisibility that is there is a positive -- I usually don't want to think about the error case, but can easily trace the exceptional path if I do. I find that often functions need to go back up the stack to handle issues, in which case the exception control flow is exactly what I want.

Runtime exceptions, on the other hand, are invisible and can be an issue, but things like running out of memory, or overflowing the stack, well, I really don't want to have to write: public int add(int x, int y) throws OutOfMemoryException, StackOverflowException, ...

For 2, I find that they just create 1 extra exit point, which is back up the stack/to the catch handler. You could certainly abuse them to cause problems, but I personally don't find this to be an issue in practice.

I think that everyone agrees that unstructured flow of control is problematic, but checked exceptions do have structure, even if it's a bit of a loose one.

[ Parent | on HN ]