Exception handling

[Ian Joyner]

There is an article on why exceptions are a bad mechanism at:

https://medium.com/internet-of-technology/error-handling-were-doing-it-all-wrong-6285821a8a44

The author mentions Eiffel exceptions, but I think lumps them with the other exception mechanisms. I have put a comment as follows:

Perhaps I have missed something, but you seem to be treating the Eiffel rescue-retry mechanism and the typical try-catch mechanism as the same. Sure they are both exception mechanisms, but they are very different.

Meyer has been very critical of the try-catch mechanism. In fact, he says it is just introducing another control structure. This seems to be at the heart of your criticism. That is try-catch blocks are something just botched into existing languages without a proper rethink (but C++ is the epitome of that disastrous thinking, and Java and C# have just copied the same thing).

The Eiffel rescue-retry mechanism is integrated with the core idea of Design by Contract (DbC is more core to Eiffel than OO).

I thought that was where you were heading, but the discussion seemed to reach an abrupt end.

I think you and Meyer probably have a common view, but I cannot be certain. It seems like you might be throwing out the baby with the bathwater.

Exceptions are an interesting topic and it seems mostly done wrong.

Many paradigms have the idea of out-of-band messaging. NaN is a rather primitive form of doing that. But actually numbers are a rather simple example, and other complex data needs a way of 'returning' the fact that a valid result could not be obtained.

I think the discussion needs continuing.

Any thoughts?

Ian

[rfo amalasoft.com]

Well said, Ian (as always), and needed to be said

R

---

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> on behalf of Ian Joyner <joyne...@gmail.com>
Sent: Saturday, April 19, 2025 8:13 AM
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Exception handling

 

--
You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/56367071-090B-48B3-8637-D96F0A7C2D7F%40gmail.com.

[Alejandro Garcia]

Hi Ian,

Thanks for your comment.

You said:

> Sure they are both exception mechanisms, but they are very different.

I would really like to understand better: how are they different?

Would you happen to have a good article (or any resource) that explains the distinction, or that describes the Eiffel rescue-retry mechanism clearly?

You also mentioned:

> Meyer has been very critical of the try-catch mechanism. In fact, he says it is just introducing another control structure.

Could you point to a reference where Meyer criticizes try-catch specifically?

Even better if the source also shows how rescue-retry avoids the pitfalls of just being another control-flow structure.

As an Eiffel beginner myself, who hasn’t used rescue-retry yet in any real code, I don’t fully see the difference yet.

Maybe, as Dijkstra said, my early exposure to Java has already "messed up" my brain too much to see it clearly! :-)

But I think many programmers are in the same situation.

Articles like the one you shared — and discussions like this — are a great opportunity for us to discover that there might be a better way...  the Eiffel way.

Thanks again for keeping the conversation going

Alejandro García F. (elviejo)

Too brief? Here's why! http://emailcharter.org

EOM – End Of Message. The whole message is in the subject don't need to open it.
NNTR – No Need To Respond. Help cut down on all those “cool” and “thanks” emails.
SINGLE SUBJECT. Send one email for one topic, this makes replies easy..
CLEAR CALL TO ACTION: Ask for some specific result very clearly.

[Ulrich Windl]

Well,

referring to dead links isn't that helpful either:


Kind regards,
Ulrich

19.04.2025 17:06:06 Alejandro Garcia <agarc...@gmail.com>:

http://emailcharter.org

[Bertrand Meyer (ETH)]

Eiffel exceptions are not a language mechanism but a method of programming for reliability based on a careful analysis developed in OOSC. People compliment the book because they read the first two and a half pages of the preface and found them less boring than the usual programming literature. Then they pontificate on exceptions without any understanding of the underlying concepts. It’s hopeless. Part of the reason is that as a result of a cabal the exceptions paper which explained these concepts was rejected at the first ECOOP and hence did not make it into the corpus. Still, people should read and learn.

 

-- BM

 

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Ian Joyner
Sent: 19 April, 2025 14:13
To: Eiffel Users <eiffel...@googlegroups.com>
Subject: [eiffel-users] Exception handling

 

There is an article on why exceptions are a bad mechanism at:

--

[Ian Joyner]

I think that might be the paper I was looking for. I remember a very clear critique of try-catch somewhere, thought it might be in OOSC2, but that was not quite what I was looking for. I had wanted to include that in my response to the medium article.

I need to brush up on the ideas, and how Eiffel exceptions are different to the exceptions being critiqued in the Medium article.

Ian

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/134c01dbb14b%2493a306c0%24bae91440%24%40inf.ethz.ch.

[Anders Persson]

Hi

This is the papper 

https://se.inf.ethz.ch/~meyer/publications/methodology/exceptions.pdf

Vänligen

Anders Persson

BSharp AB

Linked in profile

+46 763 17 23 25

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/C4FF170A-EBF0-4EAD-8464-6CD58E6D3BF6%40gmail.com.

[Ulrich Windl]

Hi!

Well, there's a tendency to claim one's own method is the only true one. Let's ignore that.
IMHO exceptions are a program flow mechanism. In Eiffel they have clear semantics. Whether an exception is to be preferred over plain condition checking is a matter of probability: For the "stack is empty" example an exception may be the right thing for pop when there's an "is empty" method.

The contract could require that the stack isn't empty for pop, guaranteeing an element will be returned, or you may call pop unconditionally, and the assertion is that you either get a valid element, or an exception.

Does anybody have a good example where none of these two do apply?

Kind regards,
Ulrich

[Ian Joyner]

Hello Ulrich,

The idea of the contract is to tell the client, that STACK.pop should not be called on an empty stack.

Thus to avoid and exception, the client should check stack.not_empty first. However, it might be they want to not bother checking (every time) and get a rare exception. This might be a valid approach if it is guaranteed that pushes and pops are always balanced. In that case an exception will indicate that the client code is not right (done one-too-many pops).

I think Eiffel makes that clear. In other languages, programmers are more likely just to toss a try-catch block around some code, just in case with no clear reason.

The Eiffel approach is at a higher, logical level, not so tied to low-level semantics. It is like C programmers get upset when I tell them that pointers are deficient. They don’t understand that links and references are between logical entities (even when a memory address is underneath), but pointers are just a memory (perhaps relative) address.

I don’t think anyone is claiming the Eiffel approach is the one true approach, just it is better.

Ian

> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/20892708-ae3b-4f1a-960e-aee4cdaa1423%40gmail.com.

[Bertrand Meyer (ETH)]

It may or may not be the "only true approach", but it is the only approach that I know that  follows from a theory of what exceptions are. If you know another please share it. (Predating Eiffel's theory was the work of Brian Randell and of Flaviu Cristian, which helped devise the concepts.)

 

The analysis is simple. A program execution carries out operations. Every operation has a contract defining its intended result. Some operations call others; they are called routines and can have their contracts specified explicitly (precondition and postcondition). Others are elementary, like an addition, with a contract usually implicit (the result must be the mathematical sum or an approximation). If everything works perfectly there is no need for an exception mechanism. In an imperfect world an operation may fail to achieve its contract. That possibility yields the first concept: failure. If the operation was not called by another, the entire execution fails. If it had a caller, then that caller’s execution gets interrupted. That is the second concept: exception. So if r’s implementation of its contract is a; b; c and b fails, then the execution of r gets an exception. If the programmer has not planned for this case then that exception immediately causes r to fail too, triggering an exception in its own caller if any, all the way up the call chain so that the whole execution fails. But in some contexts it is not reasonable to let any unforeseen event crash the whole thing so, for some routines, we may provide an alternative implementation to achieve r’s contract. This possibility is called “resumption” and is achieved in Eiffel through the “retry” construct. That’s it.

 

The key property of this analysis is that it remains in line with the key principle of programming: any operation is meant to achieve a certain contract (a specification). This is a universal rule and the presence of the exception mechanism remains in line with it. When you execute a routine, either it fails -- an notifies its caller, preventing it from proceeding as if everything were fine -- or it succeeds (meaning: achieves its contract), possibly after “retrying” a few times.

 

Following this principle, one knows precisely when (and how) to use exceptions and when not.

 

The author of the article cited by Ian Joyner mentions Design by Contract but when he comes to the resulting Eiffel exception mechanism he writes ”that’s not what I want to focus on here”. Not clear why; it could have answered the questions that he asks.

 

The very first version of Eiffel did not have exceptions, based on a simplistic analysis not unlike the author’s. Then it became clear (in part thanks to a discussion with Marc Shapiro, then as now from INRIA) that basic data structures are not enough to handle unforeseen error situations. (You are writing to the disk and the disk crashes. There is no way you can program for this. `if disk_ok then write else … end’ does not help since the crash can happen after you test but before you try to write.) Hence the analysis and mechanism. PhD theses at ETH completed the picture: by Martin Nordio on formalization, by Benjamin Morandi and Alexey Kolesnichenko on extensions to concurrency and distribution).

 

-- BM

 

 

 

-----Original Message-----
From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Ian Joyner

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/49C640A8-CC94-464B-A797-083DC52020F5%40gmail.com.

[Ian Joyner]

The polite discussion continues on Medium. Here is my reply to

which I hope makes some sense:

Hello Jules. Thanks for the response.

First you can see the thread on the Eiffel group here:

https://groups.google.com/g/eiffel-users/c/8KIPp-sLp34/m/zZlAOo3bDQAJ

and main page of the group here:

https://groups.google.com/g/eiffel-users

I think you might be reading contracts as a specification of when failure happens and exceptions raised. Contracts really are the opposite — a specification of correctly operating software.

Furthermore, contracts specify who is responsible for testing for conditions.

A requires clause tells a caller that they must check that they are passing correct arguments in correct states. Type checking is part of the contract, but that can be tested statically at compile time, in fact, the ideal situation, but not always possible. Thus dynamic tests for contract conditions are also checked in the requires clause.

A rescue clause isolates the recovery code from the pure algorithm code. And the rescue gives us the correct place to handle it.

In the case of r: a;b;c

if b fails, perhaps r must handle it. Contracts tell us that is the case or not.

"I don't get how one can regard a failure in b (whether or not it propagates to r) as being contractually sound”

Well, it isn't — b has broken the contract. Contracts are about making promises. The exceptions are when that promise is broken.

Down to the last part, we are talking about platform failure. That is some system resource like disk or memory fails, or maybe disk becomes full and a write fails.

But this is what an OS should do — provide a clean platform that does not fail in the event of failure (robustness). Sadly, many do not understand that a programming platform should do this, and thus what should be pure program code is polluted by all sorts of irrelevant considerations. This is poor separation of concerns.

In fact, I think that is the problem with try-catch is that exceptions are not cleanly separated but mixed up with the algorithm code. Hence programmers wrongly see exceptions are another kind of control structure used in algorithm code. Maybe that the basis of your original observations?

Platform resource exceptions should never be passed to a user program to handle. That is poor separation of concerns. In Unix if a process attempted a file write and the disk was full, the program failed. That is wrong. Burroughs (now Unisys) systems put the process into a wait state until either another process releases space (deletes a file), or an operator can intervene.

Note this is the modification that concurrency in SCOOP makes to contracts in Eiffel. If a requirement (as in require clause) is not met, the current process is put into a wait state until the requires is fulfilled by another process.

Really the Eiffel-style exceptions are about separating the exception code from the pure algorithm code. Without such a mechanism, we pollute our algorithm with all sort of considerations that we should not need to handle, like testing for 'disk full' results after a write.

Ultimately, contracts are about specifying separation of concerns, how those concerns are separated and who is responsible for handling the details.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/13a701dbb1f9%2463967760%242ac36620%24%40inf.ethz.ch.

[Miguel Oliveira e Silva]

Unlike Eiffel's (safe) disciplined exception mechanism, try-catch exception handling mechanism is broken [1].

The first reason why it is broken, is that it is trivial to ignore exceptions (just try-catch it, and do nothing).  For instance, in Java, it still amazes me the amount of code that do exactly that (the so called checked exceptions is, most likely, the main cause for it).

But even if a programmer would never use such an insane approach, there is a more profound reason for being broken.  Consider the following (self explained) example in Java:

double sqrt(double x) {
   assert x >= 0; // [2]
   ...
}

List<Complex> quadraticEquationSolver(double a, double b, double c) {
   assert a != 0; // [2]
   ... sqrt ...
}

If quadraticEquationSolver has an assertion failure, whose fault is it? The caller (client) or the callee (supplier)?  In the former case we are in the presence of a precondition failure (not a second degree equation), so its the client responsibility, in the latter we have a buggy implementation of the quadratic solver function (thus it is a supplier failure).  Same exception type for two *completely* different failures (and responsibilities).

"Protecting" this invocation with a try-catch will never be able to solve this elementar problem.

The problem is that functions (routines, to be more precise) are very powerful abstraction mechanisms [3].  Thus, the meaning of an exception (other than the simple and profound one given in Eiffel) is quickly washed away.  The immediate caller of a routine might (eventually) understand what a specific exception means, but its (eventual) callee most likely will not, making it impossible to attach meaning to a specific exception value. Also, the nightmare may rise to all new level if OO mechanisms such as polymorphism and dynamic binding are used (as they, in general, should), because many different implementations might be involved at runtime in a single call, each one with possible different exception values (not to mention future, not yet implemented, routines).

Eiffel's disciplined exception mechanism has not such problems and (to my knowledge) is the only exception mechanism well (and elegantly) adapted to functional and ADT abstractions.

-miguel

[1] See section 4 in: doi.org/10.4230/oasics.slate.2014.111

[2] Precondition.  Yes, it should not be a (general) assert; and also yes, it should be part of the function specification (in Portugal we have a saying that "He who has no dog hunts with a cat").

[3] In fact, one may argue that (standalone) functions exist basically to solve two problems: algorithm reuse (implement once, use many times)  and functional abstraction (function usage does not required understanding its implementation, only its interface (its contract).

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/C4FF170A-EBF0-4EAD-8464-6CD58E6D3BF6%40gmail.com.

-- 
Miguel Oliveira e Silva
IEETA-DETI, University of Aveiro, Portugal

[Ian Joyner]

Thanks Miguel, that is interesting thinking.

The discussion with Jules has continued on Medium. Here is the latest episode:

Jules May

“I think you might be reading contracts as a specification of when failure happens and exceptions raised. Contracts really are the opposite — a specification of correctly operating software.”

After all we’ve spoken about together, I can't believe you’d sugest that. Of course the contract is not about specifying when a failure happens. It's about preventing failures from happening (and, to that end, I think all contracts should be statically-checkable at compile time, in much the same way that types are).

“Platform resource exceptions should never be passed to a user program to handle”. Why not? Suppose we’re running low on ram in an embedded system. Who but the user program is able to tell which stored state is expendable? Or suppose a program has slowed to a crawl because there’s not enough ram and the pagefile is churning. Who but the user program is able to serialise the workload to recover the performance? This is my central point: to regard a subsystem or a library function as self-contained and somehow separate from the program it serves is wrong-headed. if the service is getting into trouble, it's quite reasonable for it ask the client to help it get out of trouble, before the whole system is impacted and the malfunction becomes an inevitability.

Thanks for the link, by the way.

——

My response:

“After all we’ve spoken about together, I can't believe you’d sugest that.”

OK, I’m glad you clear that up. I should have quoted what made me think that, but it was worth clarifying the point, since many would think that.

Exceptions (both kinds) really should separate what the program (or part of a program) handles and what it does not. It separates regular logic flow that decides between cases that can be handled (dispatch mechanism) from cases that can’t be handled.

As we know, programmers rightly complain that they can’t stick to one-way-in-one-way-out due to error conditions. Exceptions make it clear between the two cases, that is different handling of valid cases (dispatch) which move forward, to the error cases which go backward and ‘return’. But in that case functions have no value to return, and procedures have not been able to do what they were asked.

The progression of normal logic and regression due to failure should be distinguished. When it is not, we end up with a mess and spaghetti code requiring breaking the one-way-in-one-way-out rule for blocks. Exceptions at least give the panic escape.

Now I think your point is that regular exceptions do not address that clearly and programmers are using exceptions on the same level as other conditionals. That is a good criticism.

““Platform resource exceptions should never be passed to a user program to handle”. Why not? Suppose we’re running low on ram in an embedded system.”

No, I absolutely stick by that statement. The operating system’s job is to manage the machine resources and also its own resources, like processes. That entails handling requests for logical resources (like file operations), mapping those to physical resources so that it looks like there are always available resources and to handle any failure of the resource.

If that is not handled in the system, then client program logic is greatly complicated having to do that. Every programmer of every program must provide their own way of doing what should be handled in a single place. That is the DRY principle. That further burdens all programmers with needing to handle that. Unfortunately, many programmers think they must handle it, which is wrong.

Even in embedded systems with minimal systems, this functionality between system management and the code that actually implements our application should be clearly separated.

But I have long argued that embedded system vendors should also provide the level of system software, even if it is quite thin. Embedded vendors should provide a system, not just hardware (unless we are thinking about platforms like Raspberry Pi where system designers are interested in providing a system). Not only that, but they should provide a development environment, complete with a simple system language tied to the platform semantics.

Again, all this is about separation of concerns, which results in reuse of common code so that many programmers are not tasked with providing the same functionality in many places.

Another paper has been posted to the Eiffel group:

https://drops.dagstuhl.de/entities/document/10.4230/OASIcs.SLATE.2014.111

But this is an interesting discussion and certainly bringing out things I had not thought of before.

Ian

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/9c08c771-01e5-4eb7-9d2e-1b928b1168e9%40ua.pt.

[Ulrich Windl]

AFAIK, in Java routines declare the exceptions they are throwing and a client must handle them. Maybe that's why there are so many incomplete exception handlers.

--

Mit freundlichen Grüßen
Ulrich Windl

22.04.2025 21:26:48 Miguel Oliveira e Silva <m...@ua.pt>:

> Unlike Eiffel's (safe) disciplined exception mechanism, try-catch exception handling mechanism is broken [1].
>

> The first reason why it is broken, is that it is trivial to ignore exceptions (just try-catch it, and do nothing).  For instance, in Java, it still amazes me the amount of code that do exactly that (the so called /checked exceptions/ is, most likely, the main cause for it).

>
> But even if a programmer would never use such an insane approach, there is a more profound reason for being broken.  Consider the following (self explained) example in Java:
>
> double sqrt(double x) {
>    assert x >= 0; // [2]
>    ...
> }
>
> List<Complex> quadraticEquationSolver(double a, double b, double c) {
>    assert a != 0; // [2]
>    ... sqrt ...
> }
>
> If quadraticEquationSolver has an assertion failure, whose fault is it? The caller (client) or the callee (supplier)?  In the former case we are in the presence of a precondition failure (not a second degree equation), so its the client responsibility, in the latter we have a buggy implementation of the quadratic solver function (thus it is a supplier failure).  Same exception type for two *completely* different failures (and responsibilities).
>
> "Protecting" this invocation with a try-catch will never be able to solve this elementar problem.
>
> The problem is that functions (routines, to be more precise) are very powerful abstraction mechanisms [3].  Thus, the meaning of an exception (other than the simple and profound one given in Eiffel) is quickly washed away.  The immediate caller of a routine might (eventually) understand what a specific exception means, but its (eventual) callee most likely will not, making it impossible to attach meaning to a specific exception value. Also, the nightmare may rise to all new level if OO mechanisms such as polymorphism and dynamic binding are used (as they, in general, should), because many different implementations might be involved at runtime in a single call, each one with possible different exception values (not to mention future, not yet implemented, routines).
>
> Eiffel's disciplined exception mechanism has not such problems and (to my knowledge) is the only exception mechanism well (and elegantly) adapted to functional and ADT abstractions.
>
> -miguel
>
> [1] See section 4 in: doi.org/10.4230/oasics.slate.2014.111
>
> [2] Precondition.  Yes, it should not be a (general) assert; and also yes, it should be part of the function specification (in Portugal we have a saying that "He who has no dog hunts with a cat").
>
> [3] In fact, one may argue that (standalone) functions exist basically to solve two problems: algorithm reuse (implement once, use many times)  and functional abstraction (function usage does not required understanding its implementation, only its interface (its contract).
>
>
> On 20/04/25 00:14, Ian Joyner wrote:
>> I think that might be the paper I was looking for. I remember a very clear critique of try-catch somewhere, thought it might be in OOSC2, but that was not quite what I was looking for. I had wanted to include that in my response to the medium article.
>>
>> I need to brush up on the ideas, and how Eiffel exceptions are different to the exceptions being critiqued in the Medium article.
>>
>> Ian
>>
>>> On 20 Apr 2025, at 02:53, Bertrand Meyer (ETH) <Bertran...@inf.ethz.ch> wrote:
>>>
>>> Eiffel exceptions are not a language mechanism but a method of programming for reliability based on a careful analysis developed in OOSC. People compliment the book because they read the first two and a half pages of the preface and found them less boring than the usual programming literature. Then they pontificate on exceptions without any understanding of the underlying concepts. It’s hopeless. Part of the reason is that as a result of a cabal the exceptions paper which explained these concepts was rejected at the first ECOOP and hence did not make it into the corpus. Still, people should read and learn.
>>>
>>>  
>>>
>>> -- BM 
>>>
>>>  
>>>

>>> *From:* eiffel...@googlegroups.com <eiffel...@googlegroups.com> *On Behalf Of *Ian Joyner
>>> *Sent:* 19 April, 2025 14:13
>>> *To:* Eiffel Users <eiffel...@googlegroups.com>
>>> *Subject:* [eiffel-users] Exception handling

>>>
>>>  
>>>
>>> There is an article on why exceptions are a bad mechanism at:
>>>
>>>  
>>>

>>> _https://medium.com/internet-of-technology/error-handling-were-doing-it-all-wrong-6285821a8a44_

>>>
>>>  
>>>
>>> The author mentions Eiffel exceptions, but I think lumps them with the other exception mechanisms. I have put a comment as follows:
>>>
>>>  
>>>
>>> Perhaps I have missed something, but you seem to be treating the Eiffel rescue-retry mechanism and the typical try-catch mechanism as the same. Sure they are both exception mechanisms, but they are very different.
>>>
>>> Meyer has been very critical of the try-catch mechanism. In fact, he says it is just introducing another control structure. This seems to be at the heart of your criticism. That is try-catch blocks are something just botched into existing languages without a proper rethink (but C++ is the epitome of that disastrous thinking, and Java and C# have just copied the same thing).
>>>
>>> The Eiffel rescue-retry mechanism is integrated with the core idea of Design by Contract (DbC is more core to Eiffel than OO).
>>>
>>> I thought that was where you were heading, but the discussion seemed to reach an abrupt end.
>>>
>>> I think you and Meyer probably have a common view, but I cannot be certain. It seems like you might be throwing out the baby with the bathwater.
>>>
>>> Exceptions are an interesting topic and it seems mostly done wrong.
>>>
>>> Many paradigms have the idea of out-of-band messaging. NaN is a rather primitive form of doing that. But actually numbers are a rather simple example, and other complex data needs a way of 'returning' the fact that a valid result could not be obtained.
>>>
>>> I think the discussion needs continuing.
>>>
>>>  
>>>
>>> Any thoughts?
>>>
>>> Ian
>>>
>>> -- 
>>> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.

>>> To unsubscribe from this group and stop receiving emails from it, send an email to _eiffel-user...@googlegroups.com_.
>>> To view this discussion visit _https://groups.google.com/d/msgid/eiffel-users/56367071-090B-48B3-8637-D96F0A7C2D7F%40gmail.com[https://groups.google.com/d/msgid/eiffel-users/56367071-090B-48B3-8637-D96F0A7C2D7F%40gmail.com?utm_medium=email&utm_source=footer]_.
>>>
>>>
>>> -- You received this message because you are subscribed to the Google Groups "Eiffel Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to _eiffel-user...@googlegroups.com_. To view this discussion visit _https://groups.google.com/d/msgid/eiffel-users/134c01dbb14b%2493a306c0%24bae91440%24%40inf.ethz.ch[https://groups.google.com/d/msgid/eiffel-users/134c01dbb14b%2493a306c0%24bae91440%24%40inf.ethz.ch?utm_medium=email&utm_source=footer]_.

>>
>> --
>> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

>> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/C4FF170A-EBF0-4EAD-8464-6CD58E6D3BF6%40gmail.com[https://groups.google.com/d/msgid/eiffel-users/C4FF170A-EBF0-4EAD-8464-6CD58E6D3BF6%40gmail.com?utm_medium=email&utm_source=footer].

> --
> Miguel Oliveira e Silva
> IEETA-DETI, University of Aveiro, Portugal
>

> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/9c08c771-01e5-4eb7-9d2e-1b928b1168e9%40ua.pt[https://groups.google.com/d/msgid/eiffel-users/9c08c771-01e5-4eb7-9d2e-1b928b1168e9%40ua.pt?utm_medium=email&utm_source=footer].

[Bertrand Meyer (ETH)]

Only for programmer-defined exceptions -- which actually encourages programmers to use exceptions as a control structures (as opposed to a mechanism for recovering from abnormal cases that *cannot* be handled by normal control structures. The difficult cases are non-programmer-defined exceptions: bad events that could occur beyond the programmer's control.

The first time I saw this Java requirement I thought it was a good idea: a contract-like mechanism that specifies to the caller what can go wrong in the routine. But then I realized it does not help since it is only for programmer-defined exceptions. Most of the time where a Java programmer uses defines such an exception type using a precondition would be simpler and safer. So in the end, unfortunately, although it is a commendable attempt to provide some sanity it does not really help.

-- BM

-----Original Message-----
From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Ulrich Windl
Sent: 23 April, 2025 14:19
To: eiffel...@googlegroups.com
Subject: Re: [eiffel-users] Exception handling

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/0eb41c3b-4b3d-48fd-b771-e89b2959fc7a%40gmail.com.

[Ulrich Windl]

I wonder: Aren't platform exceptions passed to Eiffel programs? In the past they were. Maybe not out of memory, but things like bus error.

[Ian Joyner]

That would be a fault of the platform, not of Eiffel or other language.

As I said to Jules, Burroughs platforms handle that case, using a SCOOP like wait, rather than unceremoniously dumping process or passing the exception to the process to handle.

That is absolutely the correct way to do things.

Ian

> On 23 Apr 2025, at 22:26, Ulrich Windl <u202...@gmail.com> wrote:
>
> I wonder: Aren't platform exceptions passed to Eiffel programs? In the past they were. Maybe not out of memory, but things like bus error.
>

> --
> You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

> To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/6890c2b2-9ece-49d1-9a56-2de4b7ee38a6%40gmail.com.

[Miguel Oliveira e Silva]

Not exactly. In Java we can declare (any type of) exceptions in the method signature, but only checked exceptions are required to be handled.

There are two exceptions categories: checked exceptions and unchecked exceptions.  Unchecked exceptions are those inherited either from Error, or RuntimeException classes; all other are checked exceptions [1].

A programmer may create new exception types, checked or unchecked, by inheriting from the desired class. Only checked exceptions are statically required to be handled (either by explicitly allowing rethrowing in the method signature, or by a try-catch instruction).

IMHO, in theory checked exceptions seems a good ideia, in practice they are a catastrophe (they create exactly the problem that they were made to prevent: unhanded exceptions).

-miguel

[1] The inheritance tree for exceptions in Java is a little strange.  There an Exception class, but it is not the mother/father of all exceptions; Throwable is the topmost exception class (weird!).  Throwable has two heirs: Error and Exception; RuntimeException inherits from Exception: AssertionError is a descendant of Error.

On 23/04/25 13:18, Ulrich Windl wrote:

AFAIK, in Java routines declare the exceptions they are throwing and a client must handle them. Maybe that's why there are so many incomplete exception handlers.

-- 
Miguel Oliveira e Silva
IEETA-DETI, University of Aveiro, Portugal

[Miguel Oliveira e Silva]

(sorry for the typos)

(...)

IMHO, in theory checked exceptions seems a good idea, in practice they are a catastrophe (they create exactly the problem that they were made to prevent: unhandled exceptions).

(...)

-miguel

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/bb6f3570-2f54-452f-9b33-5c82f91676b0%40ua.pt.

[Bertrand Meyer (ETH)]

> Not exactly. In Java we can declare (any type of) exceptions in the method signature, but only checked exceptions are required to be handled.

 

Yes, sorry, I did not express myself correctly.

 

-- BM

 

From: eiffel...@googlegroups.com <eiffel...@googlegroups.com> On Behalf Of Miguel Oliveira e Silva
Sent: 23 April, 2025 16:20
To: eiffel...@googlegroups.com
Subject: Re: [eiffel-users] Exception handling

 

Not exactly. In Java we can declare (any type of) exceptions in the method signature, but only checked exceptions are required to be handled.

--

You received this message because you are subscribed to the Google Groups "Eiffel Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to eiffel-users...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/eiffel-users/bb6f3570-2f54-452f-9b33-5c82f91676b0%40ua.pt.