@Zoom

> Well, with an option/result you can always drop ("unwrap") it. This is cool 
> because now ignoring a possible error becomes explicit.

Yep, of course there is a lot of merit to that, but it's less convenient as it 
infects the return type of everything that wants to pass on the error. That's 
why I see exceptions as a happy medium.

Case in point: Recently I made an IRC bot without really thinking about error 
handling at all. Then I realised I wanted it to run forever without crashing. 
So I put `{.raises:[].}` on the main loop, and I could be confident that if it 
compiled, that meant I'd handled every eventuality - all with less effort than 
unwrapping/propagating Options.

@cumulonimbus

> Java's checked exceptions, which provide the same benefit as {.raises:[].} in 
> theory, are a failure in practice

I don't think it's quite the same, because the effects system flips the power 
structure on its head.

Example: Program X uses library Y which depends on library Z.

Java:

  * Z has a method that raises a checked exception.
  * Y got lazy and swallowed the exception.
  * X really wants to be robust, but has unexpected bugs / crashes due to Y's 
bad behaviour.
  * The author of X had no way of knowing about this until it happened, and 
can't fix it unless they patch Y.



Nim:

  * Z has a proc that raises an exception.
  * Y didn't care to handle the exception.
  * X really wants to be robust, so they put `{.raises:[].}` on their main proc.
  * The author of X cannot compile the program until they've dealt with the 
exceptions from Z.



So on a larger scale where several dependencies are involved, I suspect the 
temptation for careless people in the middle of the chain to swallow exceptions 
is greatly reduced, because their sub-dependencies aren't forcing them to 
handle it.

Not saying it would _never_ happen (e.g. maybe the middle folks are on projects 
that force `{.raises:[].}` so they take a dirty shortcut in their library to 
make the app compile again), but I think the dynamics are different enough that 
Nim's solution would cause less problems than checked exceptions.

Reply via email to