10 ms·

What about raise an exception?

by herge 10y ago

mikeash 10y ago
What about it?
masklinn 10y ago
That qualifies as error reporting in most languages using exceptions.
marxidad 10y ago
Exceptions should only be used for exceptional cases. For a parser, bad input should be expected.
- esrauch 10y ago
  You say that as fact but you must know it is a matter of opinion: I would say you should match the language idioms. For example, Python iterators and generators work by raising/throwing when there are no more items: it is fully expected and will always happen when you write a for-in loop.
  - iopq 10y ago
    That seems like bad design. Rust iterators return an Option<T>, for example.
    - andy_ppp 10y ago
      In Python a lot of flow control uses exceptions as it's cheaper to ask for forgiveness rather than permission and then still have to deal with errors.
- inimino 10y ago
  The JavaScript JSON parser throws an exception on invalid input. A benefit of this is that there is only one code path to handle any kind of failure, and another is that unhandled parse failures lead to a hard stop, which is a good default.
- detaro 10y ago
  And in many languages, they are the common way to communicate that a function can not return the data that is expected of it. Invalid input data means the parser can't produce the equivalent data structure -> exception. If the parser has some kind of partial parsing, a way to recover from errors or you are using a language in which returning explicit errors is the more common idiom, then you probably shouldn't throw an exception.
  - clock_tower 10y ago
    Throwing an exception when parsing fails, sounds like a case of exception-handling as flow of control: a bad thing even when commonly done, having a lot in common with GOTO statements. (See http://softwareengineering.stackexchange.com/questions/189222/are-exceptions-as-control-flow-considered-a-serious-antipattern-if-so-why http://softwareengineering.stackexchange.com/questions/18922... , and Ward's Wiki when it comes back up.)
    - nradov 10y ago
      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.
      - clock_tower 10y ago
        But see Djikstra on "GOTO statement considered harmful" (http://david.tribble.com/text/goto.html 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.
- stevetrewick 10y ago
  Parsing is often deeply recursive and in some languages, throwing an exception will automatically unwind the stack until it finds a handler. As well as explicitly giving you a good path and a bad path (as someone pointed out upthread) this can (again, in some languages) save a ton of repeated special case code in your parsing routines. Some languages or libraries are explicitly designed to use exceptions for flow control some strongly discourage this. Apple's ObjC error handling guide for example contains this stricture but also calls out parsing as an example of when you should do it. C.A.R 'null pointer' Hoare considered exceptions a blight on the earth that would lead to us accidentally nuking ourselves, so there's a spectrum of opinions available here.
- ubernostrum 10y ago
  You must really dislike Python, then since exceptions are used for all sorts of things that aren't unusual.
- mcherm 10y ago
  > Exceptions should only be used for exceptional cases. Why? (My thoughts on the matter: http://www.mcherm.com/reasons-why-my-code-style-is-wrong.html http://www.mcherm.com/reasons-why-my-code-style-is-wrong.htm... )

What about raise an exception?

by herge 10y ago

What about raise an exception?

mikeash 10y ago

What about it?

masklinn 10y ago

That qualifies as error reporting in most languages using exceptions.

marxidad 10y ago

Exceptions should only be used for exceptional cases. For a parser, bad input should be expected.

esrauch 10y ago
You say that as fact but you must know it is a matter of opinion: I would say you should match the language idioms. For example, Python iterators and generators work by raising/throwing when there are no more items: it is fully expected and will always happen when you write a for-in loop.
- iopq 10y ago
  That seems like bad design. Rust iterators return an Option<T>, for example.
  - andy_ppp 10y ago
    In Python a lot of flow control uses exceptions as it's cheaper to ask for forgiveness rather than permission and then still have to deal with errors.
inimino 10y ago
The JavaScript JSON parser throws an exception on invalid input. A benefit of this is that there is only one code path to handle any kind of failure, and another is that unhandled parse failures lead to a hard stop, which is a good default.
detaro 10y ago
And in many languages, they are the common way to communicate that a function can not return the data that is expected of it. Invalid input data means the parser can't produce the equivalent data structure -> exception. If the parser has some kind of partial parsing, a way to recover from errors or you are using a language in which returning explicit errors is the more common idiom, then you probably shouldn't throw an exception.
- clock_tower 10y ago
  Throwing an exception when parsing fails, sounds like a case of exception-handling as flow of control: a bad thing even when commonly done, having a lot in common with GOTO statements. (See http://softwareengineering.stackexchange.com/questions/189222/are-exceptions-as-control-flow-considered-a-serious-antipattern-if-so-why http://softwareengineering.stackexchange.com/questions/18922... , and Ward's Wiki when it comes back up.)
  - nradov 10y ago
    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.
    - clock_tower 10y ago
      But see Djikstra on "GOTO statement considered harmful" (http://david.tribble.com/text/goto.html 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.
stevetrewick 10y ago
Parsing is often deeply recursive and in some languages, throwing an exception will automatically unwind the stack until it finds a handler. As well as explicitly giving you a good path and a bad path (as someone pointed out upthread) this can (again, in some languages) save a ton of repeated special case code in your parsing routines. Some languages or libraries are explicitly designed to use exceptions for flow control some strongly discourage this. Apple's ObjC error handling guide for example contains this stricture but also calls out parsing as an example of when you should do it. C.A.R 'null pointer' Hoare considered exceptions a blight on the earth that would lead to us accidentally nuking ourselves, so there's a spectrum of opinions available here.
ubernostrum 10y ago
You must really dislike Python, then since exceptions are used for all sorts of things that aren't unusual.
mcherm 10y ago
> Exceptions should only be used for exceptional cases. Why? (My thoughts on the matter: http://www.mcherm.com/reasons-why-my-code-style-is-wrong.html http://www.mcherm.com/reasons-why-my-code-style-is-wrong.htm... )