I vaguely remember some advice about the necessity of being conservative with the number of different exception types. I can’t remember the rationale or find any on the Web, so I’m asking here. What’s wrong with having many possible exception types?
I suppose it could be something to do with something similar to type stability. A method is type stable when its return type is inferrable from the types of its arguments. I guess a similar consideration is perhaps important for exceptions, where it’s good (in what way?) if a method’s exception types that may be thrown are inferrable from the argument types (and not too numerous?).
Am I on the right track here? Is proliferation of exception types even an issue?
Nah, it’s fine.
Use lots of them.
I can’t think of any reason not to.
I feel like I would know about it if there was.
The type stability thing isn’t wrong but can’t be the reason – Julia’s optimiser only gained the ability to reason about exception types in 1.11 or 1.12.
But further type inference and optimisation apply different rules on exception paths so they cokpiie faster at cost of running slower.
In general Julia has pretty slow exceptions vs say python – don’t use them for control flow.
AFAIU, for the purpose of throwing exceptions there’s the simple error("<message here>") or you start defining your Exception subtypes.
I thought the powerful use case for exceptions is for try-catch behaviour where you dispatch your behaviour based on the type of exception you caught. Is that what you mean by control flow, and is what we should avoid doing? If so then the only proper use case would be for having clearer error messages?
You can you use throw and catch a fair bit
But you don’t want code that uses thruw and catch being hit on normal cases in your performance critical loops.
Basically exceptions begin hit should be exceptional.
In some languages exceptions are used to escape multiple levels of nested loops. In Julia that’s not idiomatic. Whe have @goto for that.
(Or putting it in a function and returning out of it)
And just to be clear error(...) does count as an exception
Ah yes, I wasn’t clear that I did know that. I guess I was poorly distinguishing from the extra effort that comes from creating Exception subtypes for throwing.
@goto scares me significantly.
Ah, that was my mindset already, thanks for this clarification, I was interpreting to avoid using try-catch in, say, between modelling code and a GUI that calls the modelling code. I’d want try-catch statements between that interfacing because the error reporting or handling at the GUI level would in many cases be desired to be different from what the modelling code reports.
Okay, I’m back to the Exception subtyping framework then, thank you for the clarification.
