Program logic bugs vs input/environmental errors (checked exceptions)

[Regan Heath via Digitalmars-d]

On Mon, 06 Oct 2014 15:48:31 +0100, Jacob Carlborg <doob at me.com> wrote:

> On 06/10/14 15:45, Andrei Alexandrescu wrote:
>
>> Knowledge doesn't have to be by type; just place data inside the
>> exception. About the only place where multiple "catch" statements are
>> used to make fine distinctions between exception types is in sample code
>> showing how to use multiple "catch" statements :o). This whole notion
>> that different exceptions need different types is as far as I can tell a
>> red herring.
>
> What do you suggest, error codes? I consider that an ugly hack.

Why?

It gives us the benefits of error code return values:
  - ability to easily/cheaply check for/compare them using "switch" on code  
value (vs comparing/casting types)
  - ability to pass through OS level codes directly

Without any of the penalties:
  - checking for them after every call.
  - losing the return value "slot" or having to engineer multiple return  
values in the language.
  - having to mix error codes in with valid return values (for int()  
functions).

We also get:
  - no type proliferation.
  - no arguments about what exception types are needed, or the hierarchy to  
put them in.

Seems like a win to me.


Of course.. it would be nicer still if there was a list of OS/platform  
agnostic error codes which were used throughout phobos and could be  
re-used by client code.  And.. (for example) it would be nice if there was  
a FileNotFound(string path) function which returned an Exception using the  
correct code allowing:
   throw FileNotFound(path);

and so on.


I do not know a lot about how exceptions are thrown and caught at the  
compiler/compiled code level, but perhaps there is even a performance  
benefit to be had if you know that only 2 possible types (Exception and  
Error) can/will be thrown..

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/