[erlang-questions] Exceptions vs Tagged Values

[Robert Virding]

The problem is that I want to differentiate between different types of 
error/exceptions. I DON'T JUST want errors or JUST exceptions. Both have 
their place. So for file:open I want errors in arguments, wrong data 
types, bad options etc. to generate exceptions as these are clearly 
programming errors and it would then be best here to generate an 
exception to indicate that this was serious and must be fixed. Other 
errors like file not existing or wrong permissions should generate a 
tagged return value.

To do this I have to keep track of the error reasons so I can 
differentiate between them and get the right handling. N.B. this has to 
be done in both directions. It is worse for the documentation as I have 
to document ALL the different error values to be able to do this separation.

A concrete example: I want to scan a list of directories searching for 
and processing a list of files in each directory. If a file/directory 
does not exist then it is not an error but just keep on going. However, 
it IS an error if I call file:open(FileName, rad) (instead of read) and 
an exception must be generated but the program is wrong.

I may have missed something but to do this, I think, very reasonable 
separation requires keeping track of which errors generate what 
tageed/exception values.

It is easy for file:open to do it but difficult for me. As it was 
originally written file:open did this. Aomething I read recently 
inidicated that it does not now do that, but I could be wrong there.

Sorry compile:file is a library function. If you are suggesting that we 
treat functions and applications, which consist of functions and are 
called through functions, differently then I think you are on very loose 
ground. What is the difference? Size, how many functions they call, if 
they are bifs, or what? If my compiler is really small has it suddenly 
become a function? I don't you can present any reasonable and 
understandable rule for separating them. Anyway I WANT the compiler to 
generate an exception if there is a program error in it. Just as I want 
to library functions to do. Should applications not generate exceptions? 
Which is what you are suggesting

I don't see why I cannot have the best of both worlds when the system 
can provide it for me. Why be forced to do a lot of extra and nit-picky 
work when the system can easily do it for me?

Have a new class in try, 'no', so I an easily get what I need and you 
can have just exceptions.

Einstein said something like "Things should be as simple as possible, 
but not too simple".

Robert

P.S. Good EUC!

Samuel Rivas wrote:
> Robert Virding wrote:
> 
>>In many cases you need to differentiate this. If file:open bombs it 
>>would be very nice to know if I couldn't open the file or if my 
>>arguments were wrong. That is not the same thing and handling them as 
>>such will not make users happy.
> 
> 
>   I suppose that is why try does not catch errors unless you force it to
> do so.
>  
> 
>>There will be written an aweful lot of wrapper functions to help you 
>>remember:
>>
>>file_open(Name, Opts) ->
>>     try file:crashing_open(Name, Opts) of
>>	Pid -> {ok,Pid}
>>     catch
>>	error:not_found -> {error,not_found};
>>	error:permission -> {error,permission};
>>
>>	<all other reasons why a file could not be opened/created>
>>     end.
> 
> 
>   I do not get that point:
> 
> file_open_tagged_version(Name, Opts) ->
> 	try file_open_throwing_version(Name, Opts) of
> 		Pid -> {ok, Pid}
> 	catch
> 		Reason -> {error, Reason}
> 	end.
> 
>   You need not know, nor write, all the possible Reasons. Naturally,
> there is the opposite version:
> 
> file_open_throwing_version(Name, Opts) ->
> 	case file_open_tagged_version(Name, Opts) of
> 		{ok, Pid} -> Pid;
> 		{error, Reason} -> throw(Reason)
> 	end.
> 
>   I do not see why throwing (or exiting, or erroring) is worse in terms
> of documentation for error cases.
> 
> 
>>BUT THEN AGAIN - it would simplify writing many of the libraries. For 
>>example in io when scanning/parsing a file there would be no need to try 
>>and recover on an error to keep going - just BANG exception and let the 
>>some other process handle it. Epp detects an error - BANG exception. 
>>Hell we could do it for the compiler as well. Why go to all the trouble 
>>to keep track of errors and warnings and return something helpful? It 
>>detects an error - BANG exception and let the user handle it. Seeing we 
>>have removed the grey area between right and exception warnings have to 
>>go - BANG exception. The compiler would return ModuleName | 
>>{ModuleName,Bin} (untagged) depending on the arguments, and the 
>>exceptions {'EXIT',wrong} and {'EXIT',unused_variable}.
> 
> 
>   Here you are talking about applications, not about functions. In both
> tagged and throwing approaches error handling is still needed somewhere
> in the application.
> 
>   Regards