Loading ...
Sorry, an error occurred while loading the content.

Re: [eiffel_software] Feature {FILE}.make_open_xxx promise too much (postcondition "is_open")

Expand Messages
  • Thomas Beale
    In our openEHR project, we have a hand-coded parser for ISO8601 dates and times, where the parse functions have pre-conditions on the strings to be correct
    Message 1 of 15 , Mar 31 10:45 PM
    • 0 Attachment
      In our openEHR project, we have a hand-coded parser for ISO8601 dates
      and times, where the parse functions have pre-conditions on the strings
      to be correct ISO8601 patterns. To do this in a sensible fashion, we
      parse the strings for functions like is_valid_iso8601_date(s: STRING)
      and report True or False, and if True, keep the AST cached, to avoid
      redoing all the parsing. I don't see other any way out of things like this.

      - thomas beale

      Helmut Brandl wrote:
      >
      > Colin LeMahieu wrote:
      > > I'm not sure what type of solution you're proposing. Removing the post
      > > condition and not throwing an exception would involve checking the
      result of
      > > each attempt, similar to C error codes.
      > >
      > > Exceptions can be used in cases where you:
      > > - Cannot pre-determine success or failure (out of memory, network send
      > > failure, file open failure, segmentation fault)
      > > - The computation expense of checking if the operation will succeed
      > > approaches the complexity of performing the operation in the first
      place
      > > e.g. parsing a string to see if it conforms to a grammar before
      generating
      > > an AST of the string based on the grammer. You might as well start
      building
      > > the AST in the first place and simply throw an exception if
      suddenly the
      > > grammar isn't valid because the time it takes to check if it's valid
      > > approaches the time it takes to generate an AST.
      >
      > Hello Colin,
      >
      > thanks for your thoughts. I am not yet convinced, but I am going to try
      > to think within your view.
      >
      > Let me try to understand what you say:
      >
      > - There are operations, where you cannot be sure about its success.
      > Create a new object, open a file, generate an AST of a input file which
      > shall conform to a grammar, etc...
      >
      > - These operations are of the kind try_it__it_may_succeed.
      >
      > - In case of failure you throw an exception.
      >
      > Ok?
      >


      --
      Thomas Beale
      Chief Technology Officer, Ocean Informatics

      Chair Architectural Review Board, openEHR Foundation
      Honorary Research Fellow, University College London
    • dlebansais
      I have a couple thoughts about this topic. ... I just created a class with a feature having a postcondition that is always violated, and there will be no
      Message 2 of 15 , Apr 1, 2009
      • 0 Attachment
        I have a couple thoughts about this topic.

        From manu:
        > Exceptions are always still raised if assertion monitoring is turned off.

        I just created a class with a feature having a postcondition that is always violated, and there will be no exception if postcondition monitoring is disabled in the project.
        Unless you're talking about something else? Anyway, it seems to me, disabled assertion monitoring shouldn't raise an exception. Otherwise where is the optimization?

        The second thing is, the exception thrown is a postcondition violation. From a client perspective, how is it supposed to react? An exception of this type indicates a fault in the called feature, when it facts the client didn't provide adequate parameters. It would make more sense to raise a precondition exception, but then we're back to the "exists" precondition problem.

        To come to the help of Manu, I do think make_open_read should raise an exception, because it can't silently fail if the file doesn't exist. That would be bad design. Or, then, call it make_test_and_open_read...

        Regards,
        David.


        --- In eiffel_software@yahoogroups.com, Helmut Brandl <helmut.brandl@...> wrote:
        >
        > Colin LeMahieu wrote:
        > > I'm not sure what type of solution you're proposing. Removing the post
        > > condition and not throwing an exception would involve checking the result of
        > > each attempt, similar to C error codes.
        > >
        > > Exceptions can be used in cases where you:
        > > - Cannot pre-determine success or failure (out of memory, network send
        > > failure, file open failure, segmentation fault)
        > > - The computation expense of checking if the operation will succeed
        > > approaches the complexity of performing the operation in the first place
        > > e.g. parsing a string to see if it conforms to a grammar before generating
        > > an AST of the string based on the grammer. You might as well start building
        > > the AST in the first place and simply throw an exception if suddenly the
        > > grammar isn't valid because the time it takes to check if it's valid
        > > approaches the time it takes to generate an AST.
        >
        > Hello Colin,
        >
        > thanks for your thoughts. I am not yet convinced, but I am going to try
        > to think within your view.
        >
        > Let me try to understand what you say:
        >
        > - There are operations, where you cannot be sure about its success.
        > Create a new object, open a file, generate an AST of a input file which
        > shall conform to a grammar, etc...
        >
        > - These operations are of the kind try_it__it_may_succeed.
        >
        > - In case of failure you throw an exception.
        >
        > Ok?
        >
        > The other view is:
        >
        > try_it
        > do
        > ....
        > ensure
        > succeeded or not succeeded
        > end
        >
        > I have to look at some real life code in both variants to get a better
        > handle on the issue. I will try to write some examples and come back soon.
        >
        > But in the pattern do_it_well_or_throw_an_exception I would at least
        > expect a hint in the header comment, that the feature might throw an
        > exception. Unfortunately Eiffel has no way to specify that a feature
        > might throw an exception.
        >
        > Helmut
        >
        >
        > >
        > > On Mon, Mar 30, 2009 at 1:29 PM, Helmut Brandl <helmut.brandl@...>wrote:
        > >
        > >> Colin LeMahieu wrote:
        > >>> DbC says that a method will fail with an exception or complete and the
        > >>> postcondition will hold. I'm not seeing how a postcondition saying the
        > >> file
        > >>> is open and throwing an exception if it can't be opened breaks that.
        > >> You are right in the sense: If you cannot keep your promise, you have to
        > >> raise an exception. Doing as if you kept your promise would be even worse.
        > >>
        > >> But why did you make a promise you cannot hold in the first place? I
        > >> don't like suppliers which promise too much.
        > >>
        > >> And think of the client. He relies on your promise. How shall the author
        > >> of the client find out, that he has to handle exceptions. Reading the
        > >> source code of FILE doesn't give him any clue.
        > >>
        > >>> OOSC2 Definition: exception cases
        > >>> E3 - Executing an operation that produces an abnormal condition detected
        > >> by
        > >>> the hardware or the operation system.
        > >> It is not an abnormal condition that a file does not exist. It is
        > >> detected by the operating system, but it is not abnormal. On the
        > >> contrary, it is quite usual.
        > >>
        > >> An asynchronous user interrupt is something abnormal and justifies an
        > >> exception. Or a corrupted filesystem ... But a non existing file that
        > >> you try to open ....?
        > >>
        > >>
        > >> Helmut
        > >>
        > >>> On Mon, Mar 30, 2009 at 12:01 PM, Helmut Brandl <helmut.brandl@...<helmut.brandl%40gmx.net>
        > >>> wrote:
        > >>>
        > >>>> Colin LeMahieu wrote:
        > >>>>> Exceptions are always still raised if assertion monitoring is turned
        > >> off.
        > >>>>> Checking if a file existed before opening it would be a race condition
        > >>>>> between the check and the file open.
        > >>>> Agreed. That is what I have said below.
        > >>>>
        > >>>>> Since there's no way to pre-check if a file exists and maintain that
        > >>>> state
        > >>>>> when the actual file-open is called, an exception seems the correct
        > >>>>> behavior.
        > >>>> I am afraid that this view is inconsistent with design by contract. You
        > >>>> make a promise that you cannot hold. Design by Contract says that the
        > >>>> client can rely on your promises as long as he fulfills his part of the
        > >>>> contract (i.e. the precondition).
        > >>>>
        > >>>> The feature "make_open_read" should not make a promise it cannot hold in
        > >>>> the first place. That is at least my understanding of DbC. Handling an
        > >>>> exception to display the message "cannot open file xxx" is an overkill.
        > >>>> Why not
        > >>>>
        > >>>> f: FILE
        > >>>> ...
        > >>>> f.make_open_read("filename")
        > >>>> if not f.is_open then
        > >>>> io.standard_error.print("cannot open file %"filename%"%N")
        > >>>> end
        > >>>>
        > >>>> Filenames are normally given by the user. If the user makes I typo in
        > >>>> the filename, the program has to handle that as a normal condition
        > >>>> (there is no contract with a human user, he has the right to provide
        > >>>> wrong input) and not as an exceptional condition (like e.g. the signal
        > >>>> from the operating system that it is going to shut down the system).
        > >>>>
        > >>>> By the way: Even if you are convinced that raising an exception is the
        > >>>> correct behaviour, how can the user of "make_open_read" know that the
        > >>>> feature is might raise an exception?
        > >>>>
        > >>>> Going to the extreme: Let us design features which promise to return
        > >>>> paradise on earth and in reality return the hell but raise an exception
        > >>>> before the end. Well designed "paradise_maker"?
        > >>>>
        > >>>> Regards
        > >>>> Helmut
        > >>>>
        > >>>>
        > >>>>> On Mon, Mar 30, 2009 at 11:20 AM, Helmut Brandl <helmut.brandl@...<helmut.brandl%40gmx.net>
        > >> <helmut.brandl%40gmx.net>
        > >>
        > >>>>> wrote:
        > >>>>>
        > >>>>>> Emmanuel Stapf [ES] wrote:
        > >>>>>>>> Do these features raise exceptions in case they don't fulfill its
        > >>>>>>>> constracts?
        > >>>>>>> Yes, they do.
        > >>>>>> Even if assertion monitoring is switched off?
        > >>>>>>
        > >>>>>> What type of assertion do I get, if assertion monitoring is switched
        > >>>>>> off? An OS signal?
        > >>>>>>
        > >>>>>> Are there any plans to change this behaviour.
        > >>>>>>
        > >>>>>> I consider that as a violation of the design by contract principle.
        > >> E.g.
        > >>>>>> the caller of {FILE}.make_open_read fulfills the precondition and gets
        > >>>>>> an exception if the file does not exist or the file does not have read
        > >>>>>> permissions.
        > >>>>>>
        > >>>>>> There is no precondition that the file to open has to exist and have
        > >> the
        > >>>>>> appropriate permission. I.e. from the spec of the feature, the caller
        > >>>>>> has absolutely no indication that he has to handle an exception.
        > >>>>>>
        > >>>>>> From my perspective there are 2 possibilities to remedy the situation:
        > >>>>>>
        > >>>>>> 1. Put into {FILE}.make_open_read etc. the appropriate precondition
        > >>>>>> (might be difficult, because due to process concurrency the
        > >> precondition
        > >>>>>> might be valid at check time of the precondition and invalid at open
        > >>>> time).
        > >>>>>> 2. Don't guarantee the success in the postcondition.
        > >>>>>>
        > >>>>>> Raising an exception seems to be strange.
        > >>>>>>
        > >>>>>> Regards
        > >>>>>> Helmut
        > >>>>>>
        > >>>>>>> Manu
        > >>>>>>>
        > >>>>>>>
        > >>>>>>>
        > >>>>>>> ------------------------------------
        > >>>>>>>
        > >>>>>>> Yahoo! Groups Links
        > >>>>>>>
        > >>>>>>>
        > >>>>>>>
        > >>>>> [Non-text portions of this message have been removed]
        > >>>>>
        > >>>>>
        > >>>>>
        > >>>>> ------------------------------------
        > >>>>>
        > >>>>> Yahoo! Groups Links
        > >>>>>
        > >>>>>
        > >>>>>
        > >>>>
        > >>>
        > >>> [Non-text portions of this message have been removed]
        > >>>
        > >>>
        > >>>
        > >>> ------------------------------------
        > >>>
        > >>> Yahoo! Groups Links
        > >>>
        > >>>
        > >>>
        > >>
        > >>
        > >
        > >
        > > [Non-text portions of this message have been removed]
        > >
        > >
        > >
        > > ------------------------------------
        > >
        > > Yahoo! Groups Links
        > >
        > >
        > >
        >
      • Peter Gummer
        ... Manu was not talking about exceptions raised by assertion failures. Manu was replying to a question about the FILE open routines. In this particular case,
        Message 3 of 15 , Apr 1, 2009
        • 0 Attachment
          dlebansais wrote:
          > >From manu:
          >
          >> Exceptions are always still raised if assertion monitoring is turned off.
          >>
          >
          > I just created a class with a feature having a postcondition that is always violated, and there will be no exception if postcondition monitoring is disabled in the project.
          > Unless you're talking about something else?

          Manu was not talking about exceptions raised by assertion failures.

          Manu was replying to a question about the FILE open routines. In this
          particular case, the exception would be raised by the operating system
          or the underlying C library. These are not assertions.

          Exceptions might be raised in Eiffel code too, by calling the raise
          routine: these are not assertions either, so they would still be raised
          with assertion monitoring turned off.

          - Peter Gummer
        Your message has been successfully submitted and would be delivered to recipients shortly.