|
|
Subscribe / Log in / New account

Ada should be mentioned when speaking of programming languages on safety

Ada should be mentioned when speaking of programming languages on safety

Posted Apr 19, 2013 8:25 UTC (Fri) by k8to (guest, #15413)
In reply to: Ada should be mentioned when speaking of programming languages on safety by andreasb
Parent article: A taste of Rust

Who catches this? the runtime or the compiler?

If the compiler, then how would you deal with it at runtime when it happens anyway? If the runtime, then what does the checker do when it happens?

The Rust choice of forcing you to write code that checks seems quite sensible.


to post comments

Severe underestimation of dev laziness

Posted Apr 19, 2013 13:34 UTC (Fri) by man_ls (guest, #15091) [Link] (3 responses)

Yes, Java also forces you to check for (checked) exceptions. We all know how well it has resulted: if I got a penny every time I have seen this in production code:
try {
  ...
} catch (Exception e) {}
I might have bought myself a few pints.

Severe underestimation of dev laziness

Posted Apr 19, 2013 19:43 UTC (Fri) by k8to (guest, #15413) [Link] (2 responses)

It's a good point.

But the Rust example makes it seem that you can't say "i don't care if it's null", but rather have to write null-case code independent from access-case code. The null-case code could be degenerate, but the access-case code still can't access the null.

Severe underestimation of dev laziness

Posted Apr 20, 2013 8:37 UTC (Sat) by man_ls (guest, #15091) [Link] (1 responses)

That is what you might think about checked exceptions: at least the regular code does not have to deal with error conditions. It is however a bad policy: the empty catch() block can mask important error conditions and continue silently as if the process was successful, instead of failing.

With Java Null Pointer Exceptions are not checked (i.e. they don't force you to check for them with a try...catch), but at least it prevents the regular code to deal with the null pointer.

My preferred practice now is to leave exceptions as they are and catch them all only at the root level, logging them carefully. This is why I abandoned checked exceptions but in a very few cases. Catching all exceptions (including unchecked) and logging them also deals nicely with null pointers, without having to write extra code at every point — which is what Rust forces you to do.

Severe underestimation of dev laziness

Posted Apr 23, 2013 19:53 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> without having to write extra code at every point — which is what Rust forces you to do.

Rust allows you to say "this value cannot be null" with less words than saying "might be null" would take. Hopefully developers would prefer the former rather than the latter (I certainly do) which means that the checks don't even have to be written. If Rust had do-syntax from Haskell, checking results in a chain of nullable calls wouldn't even be necessary. I assume some common library will probably implement ">>=" and ">>" in Rust which I'd use in a heartbeat when developing Rust rather than check for None manually everywhere.

Ada should be mentioned when speaking of programming languages on safety

Posted Apr 19, 2013 14:04 UTC (Fri) by andreasb (guest, #80258) [Link]

> Who catches this? the runtime or the compiler?

Out of range values are checked at runtime per the language specification and will raise a Constraint_Error exception when the check fails.

That said, a friendly compiler such as GNAT will print a warning when it can determine that something will unconditionally raise an exception at runtime.

> The Rust choice of forcing you to write code that checks seems quite sensible.

Ada's access types with null exclusion work exactly like that, as far as I can ascertain, only they just create warnings at compile time. Plus you get to have access types with valid null values if you so choose.

Attempting to dereference a null access will net you a Constraint_Error exception anyway, so a null exclusion just helps with pushing that exception back to the actual cause.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds