Why exceptions for error handling is so important
weaselcat via Digitalmars-d
digitalmars-d at puremagic.com
Sun Jan 11 23:45:58 PST 2015
On Monday, 12 January 2015 at 07:09:54 UTC, Tobias Müller wrote:
> Walter Bright <newshound2 at digitalmars.com> wrote:
>> On 1/11/2015 5:06 AM, Dicebot wrote:
>>> What is your opinion of approach advertised by various
>>> functional languages and
>>> now also Rust? Where you return error code packed with actual
>>> data and can't
>>> access data without visiting error code too, compiler simply
>>> won't allow it.
>>
>> It's a great question. I have a lot of experience with error
>> codes, and
>> with exceptions. I have zero with the packed scheme, though
>> that doesn't
>> stop me from having an opinion :-)
>>
>> Perhaps I misunderstand, but given A calls B calls C,
>>
>> A => B => C
>>
>> and C detects an error, and A knows what to do with the error.
>> B then
>> becomes burdened with checking for the error, invoking some
>> sort of
>> cleanup code, and then propagating it.
>>
>> Wouldn't this be uglifying B's source code?
>>
>> With exceptions, C throws, A catches, and B's cleanup happens
>> automatically.
>>
>> This matters very much for pipeline style programming (i.e.
>> ranges and algorithms).
>
> - Error codes are automatically ignored
> - Exceptions are automatically propagated
>
> IMO both are not ideal and lead to sloppy programming.
> Ignoring errors is of course worse than aborting where you
> could have
> handled the error.
>
> Rust-style "packed" errors are nice because you are forced to
> think about
> the correct handling.
There's nothing stopping you from just throwing errors out in
Rust(last I used it anyways) via empty match statements and/or
unwrap.
More information about the Digitalmars-d
mailing list