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 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 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