@aescling what are exit codes and shell “if” statements if not throws and catches

@wallhackio what do you mean by this response?

@aescling an error/exception is thrown at runtime. you cant throw an error during compilation its a non-sequitor

@wallhackio compilers don’t have runtimes?

@aescling this specific use case does not guarantee that an exception is thrown by the compiler runtime. (it could be how the compiler is chosen to run but who knows? what if the compiler is written in a language without exceptions?) it is a compiler refusing to compile because the code is errant. that is not an exception that is just program behavior

@wallhackio what if the implementation throws runtime exceptions as the most convenient way of short-circuiting on discovering an error?

@aescling @aescling yeah they can but you cant guarantee that a compiler deciding not to compile code is an exception. thats an implementation detail/design choice

@wallhackio (which is to say, you think that? because, pedantically speaking, compilers have runtimes, and can absol-utely throw exceptions during that runtime)

@vaporeon_ i’m entirely sure if i agree not but but i like this answer

@clarfonthey seeing this exact usage elsewhere is why i made this poll, because i disagree with the usage but think explaining exactly why is tricky to do in a satisfying way

@aescling yeah like, I kind of see the potential for weird semantics here

like the compiler throwing an error might be an error of its own, not identifying an error in your code

@wallhackio huh

@aescling i should clarify that if you didn't put the word "pedantic" in your poll then i would have said yes, but by putting "pedantic" in the cw i responded pedantically

@aescling colloquially a compiler can throw. thats fine to say.

@wallhackio ​

@wallhackio anyway here is something i think about that to me complicates the nomenclature at play here

now, this is not the entirety of use cases fur exception handling, but a very compelling use case fur exceptions is to handle impawsible situations about as gracefully as pawsible—even if by just crashing. the way erlang does, i guess. put a pin in that

consider you are using a strongly typed language with algebraic data structures, in which it is natural to define a data type that represents an abstract syntax trees. assuming there are no bugs in the AST definition, any construction you can make in the AST that type checks is a syntactically valid statement in the language you are writing an AST fur

so, imagine trying to compile source code whose contents entirely consist of constructing an AST in this language. if this fails to compile, you are trying to repurresent a local impawsibility, and the compiler will stop execution

is it a valid way to think about compilation in general in these same terms? is a compiler error better thought of as an expected result, or as an error state resulting from the compiler being forced into a logically impawsible state by the context in which it is oppurrating? which is to say, is it valid to conceive of compile time errors as the compiler assuming it is oppurrating in a logically consistent world, and exploding in response to a discovered inconsistency?

@aescling i dont think there is a "right answer" to that question. all i will say is that, if i designed a compiler, i would treat the case of incorrect code as an expected outcome because i would want to inform the user as clearly as possible what was wrong

@aescling @wallhackio bitch just have your compiler return Maybe<AST> instead of exploding

@aescling @wallhackio anyway the only graceful handling of an impossible situation is a fatal error i·e immediate termination of the program. the very existence of the exception implies that the situation is both possible and foreseen

@aescling 50% of people are right, 44% of people are wrong, and 6% are cowards