diff options
| -rw-r--r-- | README.md | 105 |
1 files changed, 105 insertions, 0 deletions
@@ -191,3 +191,108 @@ versus ``` if get_some_value () {...} ``` + +### Error handling + +At the moment there's really no way to handle errors. You could use guard +statements, see `examples/guard.fwd`, but they are rather limited, in that the +caller has no idea if the guard was executed or not. You could potentially +terminate the program directly, which is fine in some cases, but we might want +some way to signal to the caller that something has gone wrong and they might +want to choose what happens. + +This might be a case where exceptions or something like exceptions could be +used, though probably a more limited version of them, maybe something like +Haskell's `error` that only takes strings, or some other value type that cannot +possibly fail itself. Monadic (hope I'm using that word right) errors do seem +kind of inviting, where if one statement fails out, the error is just propagated +upwards. + +Code that excplicitly wants to handle its errors would now look something like +(assuming `!>` means "handle error") +``` +do_something() => n { + /* ok */ +} +!> e { + /* error branch, if omitted just throws the error to whoever called us? */ + println("caught an error :(((("); + println(e); /* if the error value is just a constant string */ + error "now I have overwritten your error, lol"; + /* possibly also attaches file and line numbers or something? Or is that too heavy?*/ +} +``` + +Some semantics are still a bit unclear, like how multiple calls should be +handled: + +``` +do_something() => n; +do_something_with(n) => m; +... +!> e { + /* who does this belong to? Should this be allowed at all? */ + /* at the moment I'm leaning towards binding to the closest function call */ +} +``` + + +It might also be a bit confusing to follow the code of execution: +``` +do_something() => n; +!> e {...} +do_something_with(n) => m; +... +``` + +would effectively be something like +``` +err_t err = do_something(|n|{ + do_something_with(n, |m|{ + ... + }); +}); +if (err) {...} +``` + +Now it's also a bit unclear if one should use error statements, +`std::optional` or `std::expected` to signify that something failed. I guess +it might depend on the context, but having to deal with multiple ways a function +might fail is a bit annoying in any language and something I'd like to avoid if +possible. + +`error` should still run the local destructors, but if we have something like +``` +create_some_object((*whatever_t) next) +{ + malloc(sizeof(whatever_t)) => ptr; + init_whatever(ptr) => whatever; + next(whatever); + free(whatever); +} +``` +(preferably the pointer from `malloc` would immediately be thrown into a `box` +or something, that way we could fairly easily handle its lifetime automatically +but anyway) + +this would now leak memory on each `error`, whether that be from `init_whatever` +or `next`. Technically speaking a memory leak is safe, but it should preferably be avoided whenever possible. +The fix would be something like +``` +create_some_object((*whatever_t) next) +{ + malloc(sizeof(whatever_t)) => ptr; + + init_whatever(ptr) => whatever; + !> e {free(ptr); error e;} + + next(whatever); + !> e {free(ptr); error e;} + + free(ptr); +} +``` + +but I'm not entirely certain if this can be automatically detected. In theory I +guess we could implement the `safe` and `unsafe` attributes and provide wrappers +for creating `box` pointers that immediately fix the issue, but hmm. |