Comments on: Day 15 – Something Exceptional

By: Moritz

Moritz — Fri, 16 Dec 2011 12:43:37 +0000

Perl follows the TIMTOWDI principle; it’s ok for the user to throw string errors; it’s not OK for the compiler. And exception types are what you should be matching against, yes

But even if we standardize the exception types, we need to unify the wording of the error messages, because there will be non-Perl 6 tools with which we interact. For example if you log the output from a Perl 6 application, and then change the compiler you use under the hood, it would be nice if the wording of the error messages didn’t change, so that the log analyzer doesn’t think a new class of errors occured.

By: Dag Odenhall (@donri)

Dag Odenhall (@donri) — Fri, 16 Dec 2011 11:44:59 +0000

I get the feeling that it’s considered OK to have “stringly typed” exception handling, for example smart-matching on error messages and the supposed need for standardized messages. Is it not better to standardize exception subclasses and let the message be free-form? It might still be human-friendly to standardize the messages but surely it’s more programming-friendly to match against classes/types?

By: Moritz

Moritz — Thu, 15 Dec 2011 14:23:08 +0000

X is just a namespace in which exceptions go by default, but it's not mandatory to put them there. There is currently no type constraint for what you can throw. die "some string" and die 404 both work, but the mechanism that catches the exceptions will wrap them into an object of type Exception, which provides the backtrace and other meta data. I'm not sure yet if that exact mechanism is here to stay, but we will continue to allow the user throw exceptions without first writing classes for it.

By: fox

fox — Thu, 15 Dec 2011 14:11:22 +0000

very nice ! but some questions( about the language):

I suppose the X class(?) is the generic exception ? will there be type constraints on what can be throw ?, like, it must do ‘X’ ?