caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] Detecting missed checks for error indications in ML code
@ 2021-01-24 11:42 Markus Elfring
  2021-01-24 14:08 ` Hendrik Boom
  2021-01-24 14:34 ` Oliver Bandel
  0 siblings, 2 replies; 13+ messages in thread
From: Markus Elfring @ 2021-01-24 11:42 UTC (permalink / raw)
  To: caml-list

Hello,

OCaml belongs also to the category of functional programming languages.
Thus the last expression in a function usually becomes the result of
the data processing which was specified in a ML source file.
This would usually happen also if the return value from a function call
indicates an error code (when a function implementation does not throw an exception
according to an error situation).

I got the impression that corresponding error checks can occasionally be missing.
How do you think about to detect such cases by advanced source code analysis?

Regards,
Markus

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 11:42 [Caml-list] Detecting missed checks for error indications in ML code Markus Elfring
@ 2021-01-24 14:08 ` Hendrik Boom
  2021-01-24 15:28   ` Markus Elfring
  2021-01-24 14:34 ` Oliver Bandel
  1 sibling, 1 reply; 13+ messages in thread
From: Hendrik Boom @ 2021-01-24 14:08 UTC (permalink / raw)
  To: caml-list

On Sun, Jan 24, 2021 at 12:42:23PM +0100, Markus Elfring wrote:
> Hello,
> 
> OCaml belongs also to the category of functional programming languages.
> Thus the last expression in a function usually becomes the result of
> the data processing which was specified in a ML source file.
> This would usually happen also if the return value from a function call
> indicates an error code (when a function implementation does not throw an exception
> according to an error situation).
> 
> I got the impression that corresponding error checks can occasionally be missing.
> How do you think about to detect such cases by advanced source code analysis?

Hard to do without knowing how the function encodes error information in its 
return value.  For example, is it success or failure that it indicates by 
returning the value zero?

A ver simple approach is to return a disjoint union -- a choice between 
a valid valid or an invalid value of another type.  THen, of course, the 
compiler's type checker will prevent any use of the valid value without a 
check being performed.

-- hendrik

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 11:42 [Caml-list] Detecting missed checks for error indications in ML code Markus Elfring
  2021-01-24 14:08 ` Hendrik Boom
@ 2021-01-24 14:34 ` Oliver Bandel
  2021-01-24 15:52   ` Markus Elfring
  1 sibling, 1 reply; 13+ messages in thread
From: Oliver Bandel @ 2021-01-24 14:34 UTC (permalink / raw)
  To: Markus Elfring; +Cc: caml-list

Hi,


Quoting  Markus Elfring <Markus.Elfring@web.de> (snt: 2021-01-24 12:42 +0100 CET) (rcv: 2021-01-24 12:42 +0100 CET):
> Hello,
> 
> OCaml belongs also to the category of functional programming languages.
> Thus the last expression in a function usually becomes the result of
> the data processing which was specified in a ML source file.
> This would usually happen also if the return value from a function call
> indicates an error code (when a function implementation does not throw an exception
> according to an error situation).
[...]

It is very common in other languages to somehow encode "errors" or
"missing values" via the result itself, by selecting a more or less
"obvius" (at the time of writing the function) value as representing an
error or missing value.
Let's call it the socilogogists approach, because I often saw
sociologists encode their data with natural numbers (starting at 1),
for say 7 or so categories, and the "no data available" was encoded as 99.

(R offers NA and NaN, but sociologists tend(ed) to use SPSS or Excel and
the 99 as exceptional value was common for decades; I think it's still
handled this way today.)

Similarly in Perl or other languages, often the empty string is used
  (undef would be better; like NULL in C, which makes sense, just don't
   dereference it; in python you have None; ...)
for indicating a certain return value, which is used like the
sociologist's 99.

But OCaml isn't just only a functional language.
It's also a typed language. And the type system can help you at this
point.
You can use the option-type for indicating missing data.
So, None and Some "" would be different.
The None indicates that there is no data available, while the Some ""
says: hey, we have data, but it's the empty string.
In that way, the empty string is not indicating a problem anymore.
And that means, that the problem you have in mind disappears!
(And if getting the empty string from the source of your data is
  indeed only possible in case of an error, return None instead of Some
  "" and you have made the conversion to a type safe return value. From
  the outside then there will be no Some "" in the set of  possibly
  returned values.)

> 
> I got the impression that corresponding error checks can occasionally be missing.
> How do you think about to detect such cases by advanced source code analysis?

No need to thest these kind of problems, as long as you use the type
system to help you as mentioned above.

Of course you can stick to the sociologists way of coding your data and
return values also in OCaml. But if you use the possibilities the
OCaml's type system offers, all that clutter with problematic values is
excluded from the beginning. No need for extra testing. Just look at the
signature of your functions.

Since a while OCaml also offers a result-type, which you can use.
It might be better than the option type in more general cases.
And if predefined types don't offer what you are looking for, just
define your own type.

Ciao,
  Oliver


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 14:08 ` Hendrik Boom
@ 2021-01-24 15:28   ` Markus Elfring
  0 siblings, 0 replies; 13+ messages in thread
From: Markus Elfring @ 2021-01-24 15:28 UTC (permalink / raw)
  To: Hendrik Boom; +Cc: caml-list

>> I got the impression that corresponding error checks can occasionally be missing.
>> How do you think about to detect such cases by advanced source code analysis?
>
> Hard to do without knowing how the function encodes error information in its
> return value.  For example, is it success or failure that it indicates by
> returning the value zero?

Such information should be provided for the safe application of programming in interfaces,
shouldn't it


> A ver simple approach is to return a disjoint union -- a choice between
> a valid valid or an invalid value of another type.  THen, of course, the
> compiler's type checker will prevent any use of the valid value without a
> check being performed.

Would you like to improve pattern matching for any OCaml data structures
directly after special function calls?

Regards,
Markus

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 14:34 ` Oliver Bandel
@ 2021-01-24 15:52   ` Markus Elfring
  2021-01-24 16:07     ` Oliver Bandel
  2021-01-24 16:18     ` Oliver Bandel
  0 siblings, 2 replies; 13+ messages in thread
From: Markus Elfring @ 2021-01-24 15:52 UTC (permalink / raw)
  To: Oliver Bandel; +Cc: caml-list

> But OCaml isn't just only a functional language.
> It's also a typed language. And the type system can help you at this point.
> You can use the option-type for indicating missing data.

I am looking more for possibilities to avoid missed checks for return values
from some function calls.


>> I got the impression that corresponding error checks can occasionally be missing.
>> How do you think about to detect such cases by advanced source code analysis?
>
> No need to thest these kind of problems, as long as you use the type
> system to help you as mentioned above.

Can it still happen then to overlook desirable checking of provided data?


> Since a while OCaml also offers a result-type, which you can use.

Do any programming interfaces need still to work without this special data type?


> It might be better than the option type in more general cases.
> And if predefined types don't offer what you are looking for,
> just define your own type.

Customised types can be constructed only for new programming interfaces.
Would you like to offer any companion functions for safer API variants?

Regards,
Markus

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 15:52   ` Markus Elfring
@ 2021-01-24 16:07     ` Oliver Bandel
  2021-01-24 16:21       ` Markus Elfring
  2021-01-24 16:18     ` Oliver Bandel
  1 sibling, 1 reply; 13+ messages in thread
From: Oliver Bandel @ 2021-01-24 16:07 UTC (permalink / raw)
  To: caml-list

Quoting  Markus Elfring <Markus.Elfring@web.de> (snt: 2021-01-24 16:52 +0100 CET) (rcv: 2021-01-24 16:52 +0100 CET):
> > But OCaml isn't just only a functional language.
> > It's also a typed language. And the type system can help you at this point.
> > You can use the option-type for indicating missing data.
> 
> I am looking more for possibilities to avoid missed checks for return values
> from some function calls.

I'm not sure what your problem is, which you want to solve.
Do you want to improve your programming (aka "coding") style?
Or do you have to deal with some code written by other people
and you fear that it's not using the type system to avoid the
problem of unclear (in the sense of "real value" vs. "error indicating
value") return values?

Do you have encountered realworld problems or are you asking just in
advance to avoid such problems in the future without having encountered
them so far?

> 
> 
> >> I got the impression that corresponding error checks can occasionally be missing.
> >> How do you think about to detect such cases by advanced source code analysis?
> >
> > No need to thest these kind of problems, as long as you use the type
> > system to help you as mentioned above.
> 
> Can it still happen then to overlook desirable checking of provided data?

If you encode the possible states of your return value as types,
then you have the advantage that when you match on the type, that
the compiler warns you about that (but if you ignore these warings, you
can get a runtime error with a non-matched value).
Also matching with the underscore can yield to unexpected results, if
used carelessly (or to avoid the compiler warnings, instead of writing
the correct match). But it often makes sense - just think about the
cases.



> 
> 
> > Since a while OCaml also offers a result-type, which you can use.
> 
> Do any programming interfaces need still to work without this special data type?

? Don't understand your question.


> 
> 
> > It might be better than the option type in more general cases.
> > And if predefined types don't offer what you are looking for,
> > just define your own type.
> 
> Customised types can be constructed only for new programming interfaces.

So write your own interface...

> Would you like to offer any companion functions for safer API variants?

?

Do you have questions on OCaml, or do you want us to write your code?


Ciao,
  Oliver

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 15:52   ` Markus Elfring
  2021-01-24 16:07     ` Oliver Bandel
@ 2021-01-24 16:18     ` Oliver Bandel
  2021-01-24 16:50       ` Markus Elfring
  1 sibling, 1 reply; 13+ messages in thread
From: Oliver Bandel @ 2021-01-24 16:18 UTC (permalink / raw)
  To: caml-list

Quoting  Markus Elfring <Markus.Elfring@web.de> (snt: 2021-01-24 16:52 +0100 CET) (rcv: 2021-01-24 16:52 +0100 CET):
> > But OCaml isn't just only a functional language.
> > It's also a typed language. And the type system can help you at this point.
> > You can use the option-type for indicating missing data.
>
> I am looking more for possibilities to avoid missed checks for return values
> from some function calls.
[...]


Effective ML (a talk by Yaron Minsky)
  https://www.youtube.com/watch?v=-J8YyfrSwTk


Ciao,
  Oliver


^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 16:07     ` Oliver Bandel
@ 2021-01-24 16:21       ` Markus Elfring
  2021-01-25  3:59         ` Yawar Amin
  0 siblings, 1 reply; 13+ messages in thread
From: Markus Elfring @ 2021-01-24 16:21 UTC (permalink / raw)
  To: Oliver Bandel; +Cc: caml-list

>> I am looking more for possibilities to avoid missed checks for return values
>> from some function calls.
>
> I'm not sure what your problem is, which you want to solve.
> Do you want to improve your programming (aka "coding") style?
> Or do you have to deal with some code written by other people
> and you fear that it's not using the type system to avoid the
> problem of unclear (in the sense of "real value" vs. "error indicating
> value") return values?

Both.

Are you used to programming concerns according to software weaknesses
like “CWE-252: Unchecked Return Value”?
https://cwe.mitre.org/data/definitions/252.html


>>> Since a while OCaml also offers a result-type, which you can use.
>>
>> Do any programming interfaces need still to work without this special data type?
>
> ? Don't understand your question.

Do you get further development ideas from another API example?
https://ocaml.org/releases/4.11/htmlman/libref/UnixLabels.html#VALsystem

Regards,
Markus

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 16:18     ` Oliver Bandel
@ 2021-01-24 16:50       ` Markus Elfring
  2021-01-29 21:14         ` [Caml-list] Error handling in FPLs (Re: Detecting missed checks for error indications in ML code) Oliver Bandel
  0 siblings, 1 reply; 13+ messages in thread
From: Markus Elfring @ 2021-01-24 16:50 UTC (permalink / raw)
  To: Oliver Bandel; +Cc: caml-list

>> I am looking more for possibilities to avoid missed checks for return values
>> from some function calls.
> [...]
>
> Effective ML (a talk by Yaron Minsky)
>   https://www.youtube.com/watch?v=-J8YyfrSwTk

How do you think about to extend the software evolution another bit also
according to information from an article like “Composable Error Handling
in OCaml” by Vladimir Keleshev (from 2018-02-12)?
https://keleshev.com/composable-error-handling-in-ocaml

Regards,
Markus

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-24 16:21       ` Markus Elfring
@ 2021-01-25  3:59         ` Yawar Amin
  2021-01-25 18:55           ` Markus Elfring
  0 siblings, 1 reply; 13+ messages in thread
From: Yawar Amin @ 2021-01-25  3:59 UTC (permalink / raw)
  To: Ocaml Mailing List

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Sun, Jan 24, 2021 at 11:22 AM Markus Elfring <Markus.Elfring@web.de>
wrote:

> ...
> Are you used to programming concerns according to software weaknesses
> like “CWE-252: Unchecked Return Value”?
> https://cwe.mitre.org/data/definitions/252.html


I would say this is a solved problem. Or at least, it can be if you program
in that way, using the result type to indicate errors. Even better, using
polymorphic variants to encode the different types of errors. But you are
already aware of this approach, since you linked to Vladimir Keleshev's
article on it.

Actually, this was a solved problem even before the result type was
introduced into OCaml, because we already had exceptions. And exceptions
were invented exactly for the purpose of ensuring that errors can never go
unnoticed. In other words, an exception ensures that either you handle it,
or the program crashes.

Of course, someone could just do a try...catch and ignore exceptions. But
at that point, no one can help them.

Regards,

Yawar

[-- Attachment #2: Type: text/html, Size: 1548 bytes --]

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Detecting missed checks for error indications in ML code
  2021-01-25  3:59         ` Yawar Amin
@ 2021-01-25 18:55           ` Markus Elfring
  0 siblings, 0 replies; 13+ messages in thread
From: Markus Elfring @ 2021-01-25 18:55 UTC (permalink / raw)
  To: Yawar Amin; +Cc: caml-list

> > Are you used to programming concerns according to software weaknesses
> > like “CWE-252: Unchecked Return Value”?
> > https://cwe.mitre.org/data/definitions/252.html <https://cwe.mitre.org/data/definitions/252.html>
>
> I would say this is a solved problem.

I got an other impression.


> Or at least, it can be if you program in that way, using the result type to indicate errors.

It seems that there are target conflicts to consider.

The data type “Stdlib.result” corresponds just to another special return value
which can also be overlooked somehow, can't it?


> Actually, this was a solved problem even before the result type was introduced into OCaml,
> because we already had exceptions.

Are there any software documentation challenges remaining for functions
that do not raise (or throw) such exceptions?


> And exceptions were invented exactly for the purpose of ensuring
> that errors can never go unnoticed.

Error handling strategies can vary considerably.
https://wiki.sei.cmu.edu/confluence/display/c/ERR00-C.+Adopt+and+implement+a+consistent+and+comprehensive+error-handling+policy


Regards,
Markus

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [Caml-list] Error handling in FPLs (Re: Detecting missed checks for error indications in ML code)
  2021-01-24 16:50       ` Markus Elfring
@ 2021-01-29 21:14         ` Oliver Bandel
  2021-01-30 11:51           ` Markus Elfring
  0 siblings, 1 reply; 13+ messages in thread
From: Oliver Bandel @ 2021-01-29 21:14 UTC (permalink / raw)
  To: caml-list

Quoting  Markus Elfring <Markus.Elfring@web.de> (snt: 2021-01-24 17:50 +0100 CET) (rcv: 2021-01-24 17:50 +0100 CET):
> >> I am looking more for possibilities to avoid missed checks for return values
> >> from some function calls.
> > [...]
> >
> > Effective ML (a talk by Yaron Minsky)
> >   https://www.youtube.com/watch?v=-J8YyfrSwTk
> 
> How do you think about to extend the software evolution another bit also
> according to information from an article like “Composable Error Handling
> in OCaml” by Vladimir Keleshev (from 2018-02-12)?
> https://keleshev.com/composable-error-handling-in-ocaml
[...]

Ah, ok, now I understand what you were talking about.
The subject, imho, implies other things.

I give the question back to you:

What do you think about this here:

Railway oriented programming: Error handling in functional languages by Scott Wlaschin
  https://vimeo.com/113707214

And about the "bind" here:
  https://dev.realworldocaml.org/error-handling.html

Does that address what you are looking for?

Ciao,
  Oliver

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [Caml-list] Error handling in FPLs (Re: Detecting missed checks for error indications in ML code)
  2021-01-29 21:14         ` [Caml-list] Error handling in FPLs (Re: Detecting missed checks for error indications in ML code) Oliver Bandel
@ 2021-01-30 11:51           ` Markus Elfring
  0 siblings, 0 replies; 13+ messages in thread
From: Markus Elfring @ 2021-01-30 11:51 UTC (permalink / raw)
  To: Oliver Bandel; +Cc: caml-list

> What do you think about this here:
>
> Railway oriented programming: Error handling in functional languages by Scott Wlaschin
>   https://vimeo.com/113707214
>
> And about the "bind" here:
>   https://dev.realworldocaml.org/error-handling.html

These links refer to helpful information.


> Does that address what you are looking for?

I am trying to increase the software development attention also for cross-cutting concerns.
Error-aware return types support the possibility to provide some data as a return value.
Under which circumstances would you actually check or overlook them?

Exception objects can not be ignored (by default) instead.

Regards,
Markus

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2021-01-30 11:51 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-01-24 11:42 [Caml-list] Detecting missed checks for error indications in ML code Markus Elfring
2021-01-24 14:08 ` Hendrik Boom
2021-01-24 15:28   ` Markus Elfring
2021-01-24 14:34 ` Oliver Bandel
2021-01-24 15:52   ` Markus Elfring
2021-01-24 16:07     ` Oliver Bandel
2021-01-24 16:21       ` Markus Elfring
2021-01-25  3:59         ` Yawar Amin
2021-01-25 18:55           ` Markus Elfring
2021-01-24 16:18     ` Oliver Bandel
2021-01-24 16:50       ` Markus Elfring
2021-01-29 21:14         ` [Caml-list] Error handling in FPLs (Re: Detecting missed checks for error indications in ML code) Oliver Bandel
2021-01-30 11:51           ` Markus Elfring

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).