DIP33: A standard exception hierarchy
Lars T. Kyllingstad
public at kyllingen.net
Tue Apr 2 22:42:09 PDT 2013
On Wednesday, 3 April 2013 at 00:07:10 UTC, Jonathan M Davis
wrote:
> [...]
> If we had IllegalArgumentException, it would likely be the base
> class for some
> subset of exceptions which were always bad arguments, but it
> certainly
> wouldn't make sense to use it by itself in most cases. It would
> just provide a
> convenient way to catch that particular subset of exceptions if
> you needed to.
I disagree. Some things don't really deserve a more detailed
error than just "illegal argument". Examples include passing a
negative number where a positive one was expected, an invalid
combination of bit flags, an invalid file mode to a file-opening
function, etc.
> In general though, I think that assert covers what
> IllegalArgumentError is
> trying to do just fine, and where it doesn't, the argument
> about needing more
> descriptive exceptions applies just as well (e.g. RangeError).
> [...]
The problem with assert is that it gets disabled in release mode.
I think it is a bad idea to have this be the "standard"
behaviour of parameter validation.
> [...]
>
> If you're treating Error exclusively as programming errors,
> then it's really
> no different from AssertError. You're just creating categories
> for specific
> types rather than using assert for them all.
Wouldn't you say that most of the Error types we have today do,
in fact, signal programming errors? Walter even argued that
OutOfMemoryError is often a programming error.
> [...]
>
> So, unless you're arguing that assertions should be left in
> code, then I don't
> think that it makes any sense to expect that Errors in general
> will stay in
> production code. [...]
I personally think that, as a general rule, Errors should stay in
production code. I thought we had already separated
-noboundscheck from -release, but I just tested now and that
doesn't seem to be the case: -release still implies
-noboundscheck.
D prides itself on being safer than C and C++, what with its
default array bounds checks to combat buffer overruns and all,
but as it turns out we're not that much better off. The -release
switch practically screams "use me in production code", but
what's the point of bounds checking if it is only ever used while
developers are testing their code?
Lars
More information about the Digitalmars-d
mailing list