Exception classes implementing interfaces

[Wagner Landgraf 43]

Just out of curiosity, I wonder if anyone implements interfaces from Exception classes? Like:

EMyException = class(Exception, IMyInterface)

Of course this would require interfaces would be non-referenced counted, but it would be a way to add arbitrary information to exceptions without having to inherit them from a specific class.

[Remy Lebeau 1394]

12 minutes ago, Wagner Landgraf said:

Just out of curiosity, I wonder if anyone implements interfaces from Exception classes?

I've never seen anyone do it, or even suggest it.  But, I don't see any reason why it couldn't be done.

[Anders Melander 1782]

4 hours ago, Remy Lebeau said:

I don't see any reason why it couldn't be done.

Yes, it probably could be done, but should it?

It's not a bad idea, but without low level compiler support (on E: IMyError do ... ) I wouldn't do it. Personally I want my error handling to be as simple and robust as possible so it doesn't potentially make a bad situation worse.

[Wagner Landgraf 43]

30 minutes ago, Anders Melander said:

Yes, it probably could be done, but should it?

It's not a bad idea, but without low level compiler support (on E: IMyError do ... ) I wouldn't do it. Personally I want my error handling to be as simple and robust as possible so it doesn't potentially make a bad situation worse.

It's an interesting approach when you have a centralize exception handler/processor mechanism - like logging systems, serializers, servers, etc.. It's a way to add metadata to the exception without having to be strict to a specific class hierarchy.

Edited October 28, 2021 by Wagner Landgraf

[Fr0sT.Brutal 900]

I don't see how it could help... if you want to extend any exception, incl 3rd party, they won't implement the interface. If you want to extend your own classes, why not inherit them from extended base class. Btw, you can wrap all exceptions thus extending ALL of them:

(pseudocode)
 

except on E:
  raise EExtended.Create(InnerException := E, AddInfo := ...)
end

Exception class even has the pointer to Inner exc already but I've never used it

[Lars Fosdal 1792]

With EurekaLog, it is possible to capture and log EVERY exception before it is handled, so why bother with interfaces?

We use inheritance, mostly to classify exceptions for a sub-domain.   
Exception
  - ParsingException

    - InvalidCSV

    - InvalidEmptyField

try
  Parse;
except
  on E:Excepetion do 
    if E is ParsingException
     then LogSomethingInformative
      else raise.
end;

 

[Dalija Prasnikar 1396]

17 hours ago, Wagner Landgraf said:

Just out of curiosity, I wonder if anyone implements interfaces from Exception classes? Like:

EMyException = class(Exception, IMyInterface)

Of course this would require interfaces would be non-referenced counted, but it would be a way to add arbitrary information to exceptions without having to inherit them from a specific class.

This sounds like a solution in search of a problem. As previously mentioned there are better options.

[Remy Lebeau 1394]

On 10/29/2021 at 12:34 AM, Fr0sT.Brutal said:

Btw, you can wrap all exceptions thus extending ALL of them:

(pseudocode)

except on E:
  raise EExtended.Create(InnerException := E, AddInfo := ...)
end

 

You have to use Exception.RaiseOuterException() to capture an InnerException, so it would look more like this:

except
  on E: Exception do begin
    Exception.RaiseOuterException(EExtended.Create(AddInfo...));
  end;
end

[Dmitriy M 10]

On 10/29/2021 at 10:52 AM, Lars Fosdal said:

try
  Parse;
except
  on E:Excepetion do 
    if E is ParsingException
     then LogSomethingInformative
      else raise.
end;

While assuming that this code snippet is just to demonstrate the point, it always raises a question in my head: why trap every possible exceptions and then re-raise if it's not the one we are expecting, if we could just trap the one we are intrested in.

try
  Parse;
except
  on E: ParsingException do
    LogSomethingInformative;
end;

 

[Fr0sT.Brutal 900]

On 10/30/2021 at 8:39 PM, Remy Lebeau said:

You have to use Exception.RaiseOuterException() to capture an InnerException, so it would look more like this:

You're right, though your solution utilizes RTL facilities while mine is fully abstract

Edited November 1, 2021 by Fr0sT.Brutal

[Lars Fosdal 1792]

Valid point. Some of my exception handlers deal with specific exception(s), as well as shared handling code. 

Hence I write it the way that I do for clarity.  An exception is already costly AF - so code efficiency is not a big deal.

 

[Anders Melander 1782]

1 hour ago, Lars Fosdal said:

Hence I write it the way that I do for clarity

How is

On 10/29/2021 at 9:52 AM, Lars Fosdal said:

on E:Excepetion do
  if E is ParsingException

 

more clear than

On 10/30/2021 at 8:15 PM, Dmitriy M said:

on E: ParsingException do

 

?

[Lars Fosdal 1792]

In that simple case, it is not more clear.