The Right Approach to Exceptions

Alex Rønne Petersen xtzgzorex at gmail.com
Sat Feb 18 13:25:03 PST 2012


On 18-02-2012 21:36, H. S. Teoh wrote:
> On Sat, Feb 18, 2012 at 08:20:23PM +0100, deadalnix wrote:
> [...]
>> However, in D, I think this is more the role of an Errors. Exception
>> are something « softer ». It will alert you on problems your program
>> encounter, but that are recoverable.
>
> I agree.
>
>
> [...]
>> Let's get an exemple : your program ask a file to the user and do some
>> operations with this file. If the file doesn't exists, you can prompt
>> for another file to the user with a meaningful message and start
>> again. However, the first version of your program can just ignore that
>> case and fail with a less specific handler in firsts versions.
>>
>> You cannot achieve something like that if you don't have a useful
>> type to rely on. Here something like FileNotFoundException is what
>> you want.
>
> Exactly.  It's important to distinguish between exceptions sometimes.
> For example:
>
> 	File promptSaveFile() {
> 		do {
> 			string filename = readInput();
>
> 			try {
> 				return File(filename);
> 			} catch(FileNotFoundException e) {
> 				writeln("No such file, please try "
> 					"again");
> 			}
> 		} while(true);
> 		assert(false);
> 	}
>
> It would not make sense for that catch to be *any* Exception; for
> example, if the exception was ReadFailureException, you do *not* want to
> catch that, but you want to propagate it.
>
> But sometimes, you *want* to handle ReadFailureException, for example:
>
> 	void salvageBadSector(out ubyte[] sector) {
> 		int n_attempts = 10;
>
> 		while(n_attempts>  0) {
> 			try {
> 				disk.read(sector);
> 			} catch(ReadFailureException e) {
> 				disk.recalibrate();
> 				n_attempts--;
> 				continue;	// try again
> 			}
> 			// If another error occurs, say OutOfMemory,
> 			// or some other unexpected problems, you do NOT
> 			// want to continue.
> 		}
>
> 		writeln("Cannot salvage data from bad sector");
> 	}
>
> Having distinct exception types allows you to do this without resorting
> to hacks, or bypassing the library altogether (because of the use of
> overly generic exception types).
>
> Having a proper exception class hierarchy is also necessary. For
> example, most programs don't care about the difference between
> FileNotFoundException and ReadFailureException; they just want to print
> an error message and cleanup if I/O fails:
>
> 	Data loadData() {
> 		try {
> 			return readFromFile();
> 		} catch(IOException e) {
> 			writeln("I/O error occurred, aborting");
> 			cleanup();
> 			exit(1);
> 		}
>
> 		assert(false);
> 	}
>
> It would be wrong to just catch Exception here, because if it wasn't an
> I/O error, but something else, it needs to be propagated!
>
>
>> The type of the exception must depend on the problem you are facing,
>> not on the module that trhow it. I see a lot of people doing the «
>> MyProgramException » or « MyLibException » but that doesn't make
>> sense. In this case, you are just making things harder.
>
> Agreed.
>
>
> [...]
>> If this politic is choosen, then It would make sense to have several
>> modules of phobos throwing exceptions of the same type, or inheriting
>> from the same base class.
>
> Phobos NEEDS to have a sane exception hierarchy. ESPECIALLY since it is
> the standard library. So you cannot assume your users cares or don't
> care about distinguishing between exception types. Some applications
> just catch Exception, cleanup and exit, but other applications need to
> know the difference between FileNotFoundException and
> ReadErrorException.
>
> So we need to design a good exception hierarchy for Phobos.
>
> The worst thing is if Phobos exceptions are too generic, then
> applications that need to tell between different problems will have to
> bypass Phobos and hack their own solution. Which is not good. The
> standard library should be maximally useful to the extent that it can
> be.

I'd just like to add to this that we don't lose anything per se by 
introducing specific exception types. People can still catch Exception 
if they really, really want.

>
>
>> Exception type is a convenient way to filter what you catch and what
>> you don't know how to handle at this point.
>
> Agreed.
>
>
> T
>

-- 
- Alex


More information about the Digitalmars-d mailing list