Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>Think about your lexer from the perspective of preconditions and postconditions. Here are two ways to design a lexer :</p> <ol> <li><p>A lexer is a device which takes in a well-formed input string and outputs a lexical analysis. The input string is required to be well-formed; if it is not then the lexical analyzer fails with an exception.</p></li> <li><p>A lexer is a device which takes an input string and produces a lexical analysis. Lexical analysis includes identification of and analysis of error conditions.</p></li> </ol> <p>Do you <em>know</em> that the string you're going to pass in is correct, and you want an exception in the exceptional circumstance that it is incorrect? Or do you <em>not know</em> that the string is correct, and you wish the lexer to determine that?</p> <p>In the former case, throw an exception. In the latter case, make the error analysis part of the output of the lexer.</p> <p>Basically what I'm saying is <a href="http://ericlippert.com/2008/09/10/vexing-exceptions/" rel="nofollow">do not produce vexing exceptions</a>. Vexing exceptions are extremely irritating. If the caller of your code is calling it to <em>determine</em> whether the string is correct then they don't want that information in the form of an exception, they want it in the form of a data object that represents the error analysis. If the purpose of the code is to produce an error analysis then <em>produce such an analysis as the normal operation of the method</em>. Do not embed the analysis in an exception and make someone trap the exception in order to get it.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload