Ticket #1298 (closed RFC: wontfix)

Opened 12 years ago

Last modified 10 years ago

opcodes, warnings, and exceptions

Reported by: particle Owned by: whiteknight
Priority: trivial Milestone:
Component: core Version:
Severity: medium Keywords:
Cc: Language:
Patch status: Platform:

Description

the api for opcodes needs review, especially with regard to the response to exceptional behavior. for example, the documentation for B<length> in src/ops/string.ops reads:

=item B<length>(out INT, in STR)

Set result $1 to the length (in characters) of string $2.
If $2 is NULL or zero length, zero is returned.

however, if a null string is passed in to length, the user should get some notification of an exceptional condition. *at least* a warning, and possibly a fatal exception.

~jerry

Change History

  Changed 12 years ago by coke

follow-up: ↓ 3   Changed 11 years ago by jkeenan

  • component changed from none to core

Is there anyone who would like to take this review on?

in reply to: ↑ 2   Changed 11 years ago by jkeenan

Replying to jkeenan:

Is there anyone who would like to take this review on?

I repeat the question.

  Changed 11 years ago by whiteknight

  • owner set to whiteknight

Unfortunately this is a pretty bit job. We have several hundred opcodes, and no clear idea for what they should do. My personal preference is to not throw exceptions where a null result does not cause a semi-predicate problem. In the case of the string opcode, returning a 0 for null or an empty string is kind of ambiguous, and we probably do want to differentiate. In another common case, such as find_method, returning a null is probably preferable to throwing an exception, I think (and there are hundreds of more examples where we would have to look on a case-by-case basis and make these kinds of decisions).

I can do a certain amount of review (and I'm happy to volunteer cotto to take a look as well), but in the end it's probably a huge amount of work. When you combine in the effort it would take to set up deprecations for everything we find that needs to change, and all the tests that we would need to update for each change, this ticket really does become unmanageably huge. I'll do what I can, but unless I hear more support for this ticket, it will probably be closed long before reaching perfect consistency.

  Changed 10 years ago by whiteknight

  • status changed from new to closed
  • resolution set to wontfix

this isn't worth doing at this point in Parrot development. We aren't going to rewrite PIR to be "sane" or "consistent". However, if we write new assembly-level languages for Parrot in the future we might do well to follow some of these lessons.

Note: See TracTickets for help on using tickets.