Opened 7 years ago

Closed 5 years ago

#2394 closed defect (wontfix)

clarify the use case for some basic exceptions

Reported by: jinmei Owned by:
Priority: medium Milestone: Remaining BIND10 tickets
Component: Unclassified Version: bind10-old
Keywords: Cc:
CVSS Scoring: Parent Tickets:
Sensitive: no Defect Severity: N/A
Sub-Project: Core Feature Depending on Ticket:
Estimated Difficulty: 3 Add Hours to Ticket: 0
Total Hours: 0 Internal?: no

Description

As discussed in #2207 (see, e.g., the relevant part of
http://bind10.isc.org/ticket/2207#comment:14), it the intended usage
of the some exceptions defined exceptions/exceptions.h
doesn't seem clear and different developers use it for different
purposes.

That's particularly so for Unexpected. When I first introduced it
(I believe it was me who added it), I intended it to mean really
"exceptional" events where we'd rather assert() the condition. An
example (not limited to that) would be failure of some system level
API that would basically be expected to succeed. Another case is an
indication of inconsistent state of a class but when we cannot 100%
eliminate the possibility that it's triggered by a (misbehaving)
application. Something like Unexpected tends to be a kitchen sink
(after all, any exception should generally indicate an "unexpected"
event, isn't it?), so I wanted to limit the use case of it.

Whether or not this intent makes sense, the reality in our code is
that it's used for other purposes like when an application passes a
NULL pointer when it shouldn't. So, there's at least some confusion
here.

The bottom line goal of this ticket is to document the intended
purpose of Unexpected. If there are other confusing exception
types, we should also clarify it in documentation.

Then, my personal proposal for Unexpected is the one I originally
intended as described above. But we can discuss that.

I also suggest unifying InvalidParameter and BadValue in this
ticket. I don't remember how we end up having these two, but it
doesn't make sense to me to separate these cases (I actually don't
even understand what's the difference between these).

Subtickets

Change History (4)

comment:1 Changed 7 years ago by jelte

  • Estimated Difficulty changed from undecided to 3

Setting this to 3; When you do this ticket, please have a short look at whether the code needs updating. If so, and it is easy, include it in this task. If so, and it is much work, create a followup ticket to do that. If not, just mention that :)

comment:2 Changed 7 years ago by shane

  • Milestone New Tasks deleted

comment:3 Changed 6 years ago by tomek

  • Milestone set to Remaining BIND10 tickets

comment:4 Changed 5 years ago by tomek

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version set to old-bind10

This issue is related to bind10 code that is no longer part of Kea.

If you are interested in BIND10/Bundy framework or its DNS components,
please check http://bundy-dns.de.

Closing ticket.

Note: See TracTickets for help on using tickets.