4 ms·
In some cases immediate action might have to be taken (like calling abort()) but very often that is not the case. Another strategy is to collect errors. Then de
by jstimpfle 8y ago
In some cases immediate action might have to be taken (like calling abort()) but very often that is not the case. Another strategy is to collect errors. Then decide what to do them at another point (no temporal or physical coupling!). After all errors are collected, you can group them, sort them, or aggregate them. Whatever is appropriate.
Looking at errors as just data avoids the "exceptional vs non-exceptional" hair splitting, and gives a lot of flexibility for code structure. I don't necessarily disagree with the Result type viewpoint as a return type from functions, but I also find it pretty pointless. Very often the best action is to separate out errors from successes into different tables immediately. A built-in Result type couples them, and encourages keeping them coupled.
Now you could argue that you can do that with Exceptions, too, by catching them immediately and treating them as data. In which case I want to ask "what's the point then?" and also refer to my topmost comment. Exceptions have a significant cost in infrastructure even if you don't actually use them...
- gdy 8y agoWhat are you going to do with the errors once you have collected them? What is the point of sorting or grouping them?
- jstimpfle 8y agoA simple example from the compiler I'm working on right now: I output type errors of expressions sorted by their location in the source file, instead of in the order they are detected. I also don't error out on the first one, but find all at once. I could also group warnings and errors together, output only the first N errors, or... whatever I fancy. Errors are just data.
- gdy 8y agoWell, this example seems somewhat contrived to me because these errors are not the errors happening in the compiler, they are diagnostic messages describing the errors in the input data. Any chance you have another example?
- jstimpfle 8y ago"An error happening in the compiler". What's that? If you mean a bug detected, then it should be handled with abort().
- gdy 8y agoAn error related to the file system, for example.
- jstimpfle 8y agoA file system error isn't an error happening in the compiler. The file system is an external system. So this error isn't really any different than a syntax error or type error. I would not treat it differently except making a different error message. Of course you cannot parse a file you cannot read, so there is a dependency which means that sooner or later you need to "act" on the error.
- gdy 8y agoWell, grouping errors in your example makes sense when all of them happened during processing a particular input which is expected to be invalid sometimes. Could you share another example where accumulating errors makes sense?
- jstimpfle 8y agoYou can do it with anything. Analyze all the files in a directory, for instance. Do all the IO in parallel and merge the results at a central point. Some files might be corrupt or whatever. Merge the results at a central point. Only then present them to the user in a sensible order. A real life example: Asynchronous webservers usually have worker threads for I/O. I/O errors need to be routed to the originators of the I/O requests (which are in other threads). Exceptions cannot do that. Here's the general point: Whether any given thing is an "Error" is highly subjective and context dependent. But clearly the error is data, so why take away the possibility to process it like any other data?