www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Error handling in C3 language

reply Kagamin <spam here.lot> writes:
https://c3-lang.org/language-common/optionals-advanced/
The language is quite nice, resembles BetterC, but also the first 
ergonomic language where I see the `Result` type in action. 
`Result` is also used for nullable types.
```
// Function returning an Optional
fn int? maybe_func() { /* ... */ }

fn void? test()
{
	// ❌ This will be a compile error
	// maybe_function() returns an Optional
	// and 'bar' is not declared Optional:
	// int bar = maybe_function();

	int bar = maybe_function()!;
	// ✅ The above is equivalent to:
	// int? temp = maybe_function();
	// if (catch excuse = temp) return excuse?;

	// Now temp is unwrapped to a non-Optional
	int bar = temp; // ✅ This is OK
}
```
But striving to be evolution of C, faults look like error code 
singletons and apparently don't carry much information.
May 29
next sibling parent =?UTF-8?Q?Ali_=C3=87ehreli?= <acehreli yahoo.com> writes:
On 5/29/25 1:18 PM, Kagamin wrote:


 But striving to be evolution of C, faults look like error code
 singletons and apparently don't carry much information.


Same here.

I've been using a macro system in a C++ library that exposes a C API. 
All implementation functions return an optional type that automatically 
errors if not checked. Equivalents of enforce(), assert(), etc. 
automatically return an invalid optional.

Here is your point: There is a constant-length buffer that collects a 
backlog of error messages from function calls. Exhausting the buffer is 
not an error; the lowest-level error messages are retained. That buffer 
is just 4K, which is 0 bytes to my eyes :).

The caller of the C API receives a C array of error strings that they 
can print to see exactly what happened. Sweet...

Oh... oh... and all formatted error messages are actually generated in a 
development build even when there are no errors, to prove that error 
messages will render and look correct when generated. (The buffer is a 
lot larger in that case, not 4K.) Very sweet indeed... :)

Ali
May 29
prev sibling next sibling parent reply Vinod K Chandran <kcvinu82 gmail.com> writes:
On Thursday, 29 May 2025 at 20:18:27 UTC, Kagamin wrote:

 https://c3-lang.org/language-common/optionals-advanced/
 The language is quite nice, resembles BetterC, but also the 
 first ergonomic language where I see the `Result` type in 
 action. `Result` is also used for nullable types.
 ```


I am also a fan of C3, done a medium size hobby project in C3 (9K 
LOC). Though, I don't like the error handling feature in C3 very 
much. I mean it's not bad, but it's not simple. I like Odin's 
simplicity.
Oct 24
parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Friday, 24 October 2025 at 11:07:40 UTC, Vinod K Chandran 
wrote:

 On Thursday, 29 May 2025 at 20:18:27 UTC, Kagamin wrote:

 https://c3-lang.org/language-common/optionals-advanced/
 The language is quite nice, resembles BetterC, but also the 
 first ergonomic language where I see the `Result` type in 
 action. `Result` is also used for nullable types.
 ```


 I am also a fan of C3, done a medium size hobby project in C3 
 (9K LOC). Though, I don't like the error handling feature in C3 
 very much. I mean it's not bad, but it's not simple. I like 
 Odin's simplicity.


Old forum post :)
Anyway, Odin just has multiple return values.
The C3 way is OK for basic things and I use something similar in 
my [D 
code](https://github.com/Kapendev/parin/blob/main/source/parin
joka/ascii.d#L913). It's a Maybe/Option type, but with an error code instead of
a bool. I don't think you should make that part of your language, or do it the
way C3 did, but ehh.
Oct 24
parent reply Vinod K Chandran <kcvinu82 gmail.com> writes:
On Saturday, 25 October 2025 at 03:13:40 UTC, Kapendev wrote:


On Saturday, 25 October 2025 at 03:13:40 UTC, Kapendev wrote:

 Old forum post :)
 Anyway, Odin just has multiple return values.
 The C3 way is OK for basic things and I use something similar 
 in my [D 
 code](https://github.com/Kapendev/parin/blob/main/source/parin
joka/ascii.d#L913). It's a Maybe/Option type, but with an error code instead of
a bool. I don't think you should make that part of your language, or do it the
way C3 did, but ehh.


Yes, multiple return values are the foundation of Odin’s error 
handling. By the way, I am a big fan of your Joka library. I was 
looking for a starting point to learn betterC because I plan to 
create a Windows-only GUI library using D + betterC, but I did 
not know where to start. I searched the forum and found your 
library. You did an excellent job; thank you for that.
Nov 02
parent reply Kapendev <alexandroskapretsos gmail.com> writes:
On Monday, 3 November 2025 at 04:32:35 UTC, Vinod K Chandran 
wrote:

 Yes, multiple return values are the foundation of Odin’s error 
 handling. By the way, I am a big fan of your Joka library. I 
 was looking for a starting point to learn betterC because I 
 plan to create a Windows-only GUI library using D + betterC, 
 but I did not know where to start. I searched the forum and 
 found your library. You did an excellent job; thank you for 
 that.


Thanks! If you run into any BetterC issues, just ask. I want to 
write a short guide on common BetterC errors and fixes, but 
haven't yet.
Nov 03
next sibling parent Vinod K Chandran <kcvinu82 gmail.com> writes:
On Monday, 3 November 2025 at 10:24:06 UTC, Kapendev wrote:

 On Monday, 3 November 2025 at 04:32:35 UTC, Vinod K Chandran 
 wrote:

 Yes, multiple return values are the foundation of Odin’s error 
 handling. By the way, I am a big fan of your Joka library. I 
 was looking for a starting point to learn betterC because I 
 plan to create a Windows-only GUI library using D + betterC, 
 but I did not know where to start. I searched the forum and 
 found your library. You did an excellent job; thank you for 
 that.


 Thanks! If you run into any BetterC issues, just ask. I want to 
 write a short guide on common BetterC errors and fixes, but 
 haven't yet.


Sure, I was hesitant to start because there are not many 
tutorials about this subject. Eagerly waiting for your short 
guide.
Nov 03
prev sibling parent reply monkyyy <crazymonkyyy gmail.com> writes:
On Monday, 3 November 2025 at 10:24:06 UTC, Kapendev wrote:

 If you run into any BetterC issues, just ask.


I once used worseD and I had to reimpliment writeln because 
import std didnt work; how do I stop from saying "adr is right"?
Nov 03
parent Kapendev <alexandroskapretsos gmail.com> writes:
On Monday, 3 November 2025 at 16:44:03 UTC, monkyyy wrote:

 On Monday, 3 November 2025 at 10:24:06 UTC, Kapendev wrote:

 If you run into any BetterC issues, just ask.


 I once used worseD and I had to reimpliment writeln because 
 import std didnt work; how do I stop from saying "adr is right"?


Hmm... First of all, great question! Asking that means that you 
are ready to explore and learn new things. Let's see... Maybe you 
have a skill issue. Even if you have one though, you should still 
not stop saying "adr is right". Adr is usually right about things.
Nov 03
prev sibling parent reply user1234 <user1234 12.de> writes:
On Thursday, 29 May 2025 at 20:18:27 UTC, Kagamin wrote:

 https://c3-lang.org/language-common/optionals-advanced/
 The language is quite nice, resembles BetterC, but also the 
 first ergonomic language where I see the `Result` type in 
 action. `Result` is also used for nullable types.
 ```
 // Function returning an Optional
 fn int? maybe_func() { /* ... */ }

 fn void? test()
 {
 	// ❌ This will be a compile error
 	// maybe_function() returns an Optional
 	// and 'bar' is not declared Optional:
 	// int bar = maybe_function();

 	int bar = maybe_function()!;
 	// ✅ The above is equivalent to:
 	// int? temp = maybe_function();
 	// if (catch excuse = temp) return excuse?;

 	// Now temp is unwrapped to a non-Optional
 	int bar = temp; // ✅ This is OK
 }
 ```
 But striving to be evolution of C, faults look like error code 
 singletons and apparently don't carry much information.


Slightly related, if I've followed correctly the yesterday 
cloudflare outage was cause because a Result value was unwrapped 
without actually checking if it's valid.

https://www.reddit.com/r/rust/comments/1p0susm/cloudflare_outage_on_november_18_2025_caused_by/
Nov 19
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 20/11/2025 1:58 AM, user1234 wrote:

 Slightly related, if I've followed correctly the yesterday cloudflare 
 outage was cause because a Result value was unwrapped without actually 
 checking if it's valid.
 
 https://www.reddit.com/r/rust/comments/1p0susm/ 
 cloudflare_outage_on_november_18_2025_caused_by/


For D devs what happend was:

A limit was reached by a bad input file that they pushed to production.

When that limit was exceeded they went and called abort and it killed 
the process.

It then took a while to recover.

In D what you should do is throw an Error if it cannot be handled locally.

Kill the task/coroutine/fiber, report back with stack trace (by catching 
the Error). Allow further connections.

Reverting the file would be easy enough to do if you have all the 
information required to do so within the exception.

Going oh look the runner is up! Nope its down, aw its up again! wahoo, 
nope its down... Isn't very helpful when the process isn't the issue.
Nov 19