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