[bug#60802] [PATCH v3 1/2] platforms: Raise an exception when no suitable platform is found.

[Simon Tournier]

Hi,

On mar., 17 janv. 2023 at 09:59, Ludovic Courtès <ludo@gnu.org> wrote:
> Josselin Poiret <dev@jpoiret.xyz> skribis:
>
>> This looks good to me, although in the grand scheme of things I wonder
>> if that change is a step forward: for those kinds of procedures, we
>> could expect consumers to instead always properly handle the #f case
>> themselves, rather than baby-sitting them and systematically relying on
>> exceptions in the parent procedure, no?  As a caricatural example: the
>> SRFI-1 `find` could raise an exception instead of returning #f, but I
>> don't think anyone would consider that proper behaviour.
>
> I share this sentiment in general (plus the fact that we should keep UI
> aspects, such as error reports, separate from core logic).  Here there’s
> a precedent with other lookup procedures though
> (‘lookup-bootloader-by-name’, ‘lookup-compressor’,
> ‘lookup-image-type-by-name’, etc.), so I think it’s okay to keep it that
> way.

Well, from my small experience with other programming language, they
barely do return a boolean when they fail.  I think this way using a
boolean is because some historical reasons when exceptions was not
implemented in Scheme (or other languages).

Exception allows the motto: «ask for forgiveness, not permission» while
keeping under control the side effects.  Well, IMHO exception is often a
good practise for dynamically typed programming language; as Scheme (or
Python).

>From my point of view, exception is not related to “should keep UI
aspects, such as error reports, separated from core logic”.  This is how
the exception is handled.  It is often easier to propagate exception
until an handler than propagate a boolean (as with ’find’).

And if the exception is not handled, then it just returns a backtrace,
which is more informative, IMHO.


For instance, Python returns an exception:

--8<---------------cut here---------------start------------->8---
$ guix shell python python-ipython -- ipython
Python 3.9.9 (main, Jan  1 1970, 00:00:01) 
Type 'copyright', 'credits' or 'license' for more information
IPython 8.2.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: lst = [1,2,3]
lst = [1,2,3]

In [2]: lst.index(2)
Out[2]: 1

In [3]: lst.index(10)
---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
Input In [3], in <cell line: 1>()
----> 1 lst.index(10)

ValueError: 10 is not in list
--8<---------------cut here---------------end--------------->8---

For other instances, OCaml implements two ’find’ [1], one using an
exception and another using a Maybe monad (named ’option’).

--8<---------------cut here---------------start------------->8---
val find : ('a -> bool) -> 'a list -> 'a
Raises Not_found if there is no value that satisfies f in the list l.

val find_opt : ('a -> bool) -> 'a list -> 'a option
--8<---------------cut here---------------end--------------->8---

Haskell returns a Maybe monad [2]:

--8<---------------cut here---------------start------------->8---
find :: Foldable t => (a -> Bool) -> t a -> Maybe a 
--8<---------------cut here---------------end--------------->8---

Well, from a signature point of view, ’find’ from SRFI-1 returns an
union type (value or boolean) which can lead to hard to detect bugs:
when composing functions, the error can be incorrectly pointed by the
compiler to a totally unrelated place.

Instead, the exception allows to keep an expected signature (say one
value as with ’find’) but raises the error at the correct place.  If
there is no handler, it just raises the backtrace.

>From my point of view, code using exception cannot be worse* than
without.  That’s my general sentiment. :-)

*worse: for sure, we could discuss some performance penalty depending on
        the context.

1: <https://v2.ocaml.org/api/List.html>
2: <https://hackage.haskell.org/package/base-4.17.0.0/docs/Data-List.html>


Cheers,
simon